> -----Original Message-----
> From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 14, 2004 7:14 PM
> To: Slide Developers Mailing List
> Subject: Re: New feature for internally repeating conflicting requests
>
>
> On Tue, 14 Dec 2004 15:50:01 -0800, Warwick Burrows
> <[EMAIL PROTECTED]> wrote:
> >
> > Oliver,
> >
> > Unforunately DB2 doesn't seem to set the error code in the
> vendorCode
> > field as you would expect it to do, but the StandardRDBMSAdapter
> > createException implementation picks up the concurrency
> error with its
> > state string check instead.
>
> Is there anything set in the error code? If not does the code
> in StandardRDBMSAdapter#createException work for DB2?
It is picking up the exception from the string code eg. "40001". But the
debugger shows that the vendorCode is 0 and the nested exception seems to
contain nothing as well and continues to nest other exceptions to infinite
depth.
> > 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.
> > the return paths for the exception to verify the exception
> would make
> > it back to the AbstractWebdavMethod.run() method? I'm wondering how
> > your tests of the feature worked :-) I am trying to integrate the
> > changes you made for
>
> So, how did you test this?
I'm using a debugger and followed the ConcurrentConflictException back from
when it was thrown in the store.
> > this feature now and ran into this while reproducing my DB2
> conflict
> > problem. I'm not working from a comprehensive list of
> changed files,
> > but I did compare my LockMethod module with what's in the head and
> > they are the same except for a "fine-grain" lock change.
> >
> > Do you have a comprehensive list of the files that changed to
> > implement this feature?
>
> Sorry, no idea what you are trying to do...
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.
>
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
