On Tue, 14 Dec 2004 17:52:02 -0800, Warwick Burrows
<[EMAIL PROTECTED]> wrote:
> > > A real problem is that the ConcurrencyConflictException
> > doesn't make
> > > it past LockMethod when it bubbles up from the store. In LockMethod
> > > its caught in a generic Exception catch block at line 368 and
> > > converted into a WebdavException. This may happen in other methods
> > > too. Had you looked at all
> >
> > Have you considered this:
> >
> > public class ConcurrencyConflictException extends
> > /*
> > * XXX: this must be an error to ensure it gets
> > caught in the webdav
> > * layer only
> > */Error {
> >
> > Line 368 catches an Exception, not an Error, that's the trick ;)
>
> And it would be great except that AbstractStore.java catches "throwables"
> including Errors and is wrapping the Error inside a ServiceAccessException
> which is then thrown back to LockMethod.
Argh! You are right! I was only provoking to throw this exception from
the core. I'd say the problem is in AbstractStore, it certainly should
not catch errors...
> I need to fix this concurrency issue in Slide so we can go into our QA load
> test phase next week :-) I was trying to work back from the changes you had
> made to AbstractWebdavMethod and the db stores for this retry feature but
> really need a list of the files you changed so I can merge them back into
> our 2.1 source tree. I don't have the submission logs for the defects you
> submitted for this feature.
We not go for CVS head then?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
