Sorry, but I'm not sure what you mean. I'd like to understand the problem with the global mutex and transactions lock a little better. Is the global lock a DB lock too or is it just a standard mutex lock? If it's a normal mutex lock then are the incoming requests acquiring the locks in the wrong order? Can you explain what causes the distributed deadlock?
Thanks, Warwick > -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 16, 2004 5:44 AM > To: Slide Developers Mailing List > Subject: Re: New feature for internally repeating conflicting requests > > > This is a distributed deadlock which can not be resolved. > That's why Slide locks must be disabled when using external > transactions. > > Oliver > > > On Wed, 15 Dec 2004 17:43:31 -0800, Warwick Burrows > <[EMAIL PROTECTED]> wrote: > > > > 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] > > > > > > --------------------------------------------------------------------- > 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]
