db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Re: Releasing latches when waiting for locks. When and why?
Date Wed, 22 Nov 2006 13:48:54 GMT
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?

-- 
dt


Mime
View raw message