And not with the type of deadlock condition (eg. -911) that times out. It is hung up in the db2 client making an "assureUriId" INSERT call to the database and the other thread is waiting on the global lock. I have no idea how or even why making enabling global locking for external transactions would cause this problem.
Warwick > -----Original Message----- > From: Warwick Burrows [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 15, 2004 7:39 PM > To: 'Slide Developers Mailing List' > Subject: RE: New feature for internally repeating conflicting requests > > > > Sorry, I should have been clearer. I have the same problem > with full mode as without it (ie. write sequential mode). > > And its no wonder since the global locks used to implement it > aren't used when an external transaction is active. Eg. from > AbstractWebdavMethod.java: > > if (!slideToken.isExternalTransaction()) { > token.begin(); > transactionIsStarted = true; > if (txForAllRequests()) { > slideToken.setForceStoreEnlistment(true); > } > > if (this instanceof ReadMethod) { > assureGlobalReadLock(); > } else if (this instanceof WriteMethod) { > assureGlobalWriteLock(); > } > globalLockObtained = true; > } > > I tried taking the lock piece outside of this condition but > the server deadlocks. > > Warwick > > > > -----Original Message----- > > From: Warwick Burrows [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, December 15, 2004 7:27 PM > > To: 'Slide Developers Mailing List' > > Subject: RE: New feature for internally repeating > conflicting requests > > > > > > > > Nope. Unfortunately that doesn't work either. > > > > > > > -----Original Message----- > > > From: Warwick Burrows [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, December 15, 2004 7:23 PM > > > To: 'Slide Developers Mailing List' > > > Subject: RE: New feature for internally repeating > > conflicting requests > > > > > > > > > > > > Ok. I'll try that. > > > > > > > > > > -----Original Message----- > > > > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, December 15, 2004 7:04 PM > > > > To: Slide Developers Mailing List > > > > Subject: Re: New feature for internally repeating > > > conflicting requests > > > > > > > > > > > > It should not deadlock when you have sequential-mode as "full" > > > > turned on. That's the way to go for 2.1... > > > > > > > > Oliver > > > > > > > > > > > > On Wed, 15 Dec 2004 13:34:22 -0800, Warwick Burrows > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > I agree with you about new features and 2.1. Unfortunately > > > > my company > > > > > can't go into QA or production with -911 errors failing our > > > > > transactions so I will just have to keep any changes I > > > make to fix > > > > > this problem with 2.1 in my own sandbox and won't submit > > > them back > > > > > unless they apply to the HEAD. Then I will have to wait > > until 2.2 > > > > > before I can sync my tree up with CVS again. And if that's > > > > the way it > > > > > has to be then I'm fine with that. > > > > > > > > > > My concern is that the Slide 2.1 release is not > > suitable for any > > > > > scenarios where load is important while this problem is > > > > outstanding in > > > > > the 2.1 tree. Though I agree your solution is a feature, it > > > > could also > > > > > be considered as a bug fix since Slide returns a 500 > > error when it > > > > > gets this exception and applications don't have a way to > > > deal with > > > > > that. > > > > > > > > > > Warwick > > > > > > > > > > > -----Original Message----- > > > > > > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > > > > > > Sent: Wednesday, December 15, 2004 10:59 AM > > > > > > To: Slide Developers Mailing List > > > > > > Subject: Re: New feature for internally repeating > conflicting > > > > > > requests > > > > > > > > > > > > > > > > > > On Wed, 15 Dec 2004 17:07:26 +0100, Oliver Zeigermann > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > On Wed, 15 Dec 2004 16:55:58 +0100, Oliver Zeigermann > > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > 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? > > > > > > > > > > > > > > One more reason for you to stick to the CVS head for new > > > > > > features is > > > > > > > shown by this issue. There will be no support for this > > > > > > retry feature > > > > > > > in 2.1 and it isn't even alpha, yet (as we have seen). > > > > It needs to > > > > > > > evolve and mature with a full 2.2 release cycle. > > > > > > > > > > > > Still another example of the worth of community based open > > > > > > development. I implement a new feature in the open, others > > > > > > contribute like you and finally it gets going. So, do > > > not create > > > > > > your own branch... > > > > > > > > > > > > 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] > > > > > > > > --------------------------------------------------------------------- > > 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]
