db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Releasing latches when waiting for locks. When and why?
Date Mon, 27 Nov 2006 15:38:03 GMT
One approach would be to continue to support the latching in the
lockmanager, but to provide an alternate implementation using the
same interfaces (or new interfaces if necessary).  Then make the
default module implementation be the new improved one, but if a
deadlock is suspected run under the existing lockmanager with
all the exising nobs/reporting for deadlock and timeout.

Dyre.Tjeldvoll@Sun.COM wrote:
> Knut Anders Hatlen <Knut.Hatlen@Sun.COM> writes:
>>Daniel John Debrunner <djd@apache.org> writes:
>>>Knut Anders Hatlen wrote:
>>>>Mike Matrigali <mikem_app@sbcglobal.net> writes:
>>>>>Having said that it would be interesting if someone had time to
>>>>>implement a higher performance latch implementation and plug it in
>>>>>and see how much it helps.  It would decrease the total time spent
>>>>>in lock manager.
>>>>Ok, a new experiment: I removed the calls to LockFactory.latchObject()
>>>>and LockFactory.unlatch() in BasePage. Instead, I let BasePage check
>>>>manually whether it was latched and use wait/notifyAll if it was. The
>>>>patch (which is very simple) is attached.
>>>The original decision to use the lock manager for the latches was to
>>>enable easier debugging of deadlocks during the early development of
>>>the store code. A local latch implementation, like Knut Anders made,
>>>does make a lot of sense, but does leave derby open to undetectable
>>>deadlocks. Given the performance gains it probably is worth the risk,
>>>especially since I don't think we've seen a problem with latch
>>>ordering for many years.
>>Thanks to you all for your input! I have logged DERBY-2107 and will
>>start working on a local latch implementation along the lines of the
>>patch I sent out.
> Being able to detect/debug deadlocks would be very convenient. Isn't it
> possible to write code for this that can be enabled if one
> suspects a deadlock, but has no or minimal performance impact when disabled?

View raw message