Hi Oliver, In AbstractWebdavMethod.java where you implemented the code to retry upon conflict you have a condition that there not be an external transaction in progress. Is this necessary as I'd like Slide to retry upon conflict even when the transaction was started by the client. I can't think of a reason why it would not work and catching this error condition client-side consumes more execution time since a new http request would need to be formulated for each retry.
I was going to try it all out this way in my source tree and then submit it back to 2.1. 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]
