Great thanks for the explanation.
> -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 16, 2004 1:10 PM > To: Slide Developers Mailing List > Subject: Re: New feature for internally repeating conflicting requests > > > On Thu, 16 Dec 2004 09:00:02 -0800, Warwick Burrows > <[EMAIL PROTECTED]> wrote: > > 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 > > Additional locks used in the Slide WebDAV layer are Java > locks. When using external transactions those locks are not > acquired. In both cases DB locks are acquired. > > The reason for these additional (Java) WebDAV layer locks is > that when a transaction consists of a single request only (no external > transactions) it can avoid deadlocks completely. It can as it > can acquire all locks atomically as it knows which resources > to lock beforehand. > > > mutex lock then are the incoming requests acquiring the > locks in the > > wrong order? Can you explain what causes the distributed deadlock? > > Well, you know what a deadlock is: two transctions mutually > blocking each other. The DB can find out if this is the case > as it has knowledge of all locks involved. However, when you > have both DB locks and Slide locks, the DB has no idea of the > Slide locks and can not detect a deadlock. > > 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]
