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.
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 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 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? Thanks, Warwick > -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Monday, December 13, 2004 10:07 AM > To: Slide Users Mailing List > Subject: Re: New feature for internally repeating conflicting requests > > > It's the store that reports the problem. So the 911 error > code from DB2 should be added to the DB2 store as right now > there only is the generic ANSI SQL state thing. No idea of > DB2 supports it, so I have just added it to the store right > away. Please check my change... > > Thanks, > > Oliver > > > On Mon, 13 Dec 2004 07:56:33 -0800, Warwick Burrows > <[EMAIL PROTECTED]> wrote: > > Hey Oliver, > > > > What constitutes a conflict in this regard? Do the stores > detect two > > transactions writing or reading to the same store or does the store > > itself return an error eg. the DB2 911 exception that > signifies table > > access conflict/deadlock? > > > > Thanks, > > Warwick > > > > > > > > > > > -----Original Message----- > > > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > > > Sent: Saturday, December 11, 2004 1:38 PM > > > To: Slide Users Mailing List > > > Subject: Re: New feature for internally repeating conflicting > > > requests > > > > > > > > > This has been finished. Now all stores should support this. > > > > > > Oliver > > > > > > > > > On Tue, 7 Dec 2004 18:12:53 +0100, Oliver Zeigermann > > > <[EMAIL PROTECTED]> wrote: > > > > Sorry, messed up the subject... > > > > > > > > On Tue, 7 Dec 2004 18:11:49 +0100, Oliver Zeigermann > > > > <[EMAIL PROTECTED]> wrote: > > > > > Folks, > > > > > > > > > > I have added a new option to internally and transparently > > > repeat a > > > > > transaction if it has failed becasue of concurrency > > > confclits. Right > > > > > now only tx file and mysql support this experimental feature. > > > > > > > > > > There are two new parameters in the configuration section of > > > > > Domain.xml repeat-upon-conflict which enables this > feature and > > > > > max-retry-repeat which sets the maximum number of > > > repeats, defaults > > > > > are "false" and "1". > > > > > > > > > > E.g. this > > > > > <parameter > > > name="repeat-upon-conflict">true</parameter> > > > > > <parameter name="max-retry-repeat">5</parameter> > > > > > > > > > > enables the repeast feature and sets the maximum number > > > of repeats > > > > > to 5. > > > > > > > > > > If it is disabled everything should work just as before. > > > > > > > > > > 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] > > > > > > --------------------------------------------------------------------- > 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]
