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?
> 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 ;)
> 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?
> 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...
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
