db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Releasing latches when waiting for locks. When and why?
Date Thu, 07 Dec 2006 10:33:33 GMT
Olav Sandstaa <Olav.Sandstaa@Sun.COM> writes:

> Knut Anders Hatlen wrote:
>> Mike Matrigali <mikem_app@sbcglobal.net> writes:
>>
>>   
>>> 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.
>>>     
>>
>> That's an excellent idea! I think it's possible to do this without
>> creating a new module. We could for instance have a property which
>> told SinglePool.latchObject() whether or not it should go through the
>> lock table. I will investigate how this could be done and possibly
>> come up with a new patch for DERBY-2107.
>>   
>
> I think you should go for your original approach where you just move
> the latching out of the lock manager and to the page level. In
> addition to the large performance improvement, this is a simple
> solution where the code is easy to understand and maintain. It also
> gives the opportunity to simplify the lock manager interface by being
> able to remove the latch specific methods from SinglePool (which IMHO
> did not fit well into a generic lock manager interface).

I started looking at how this could be achieved, but I didn't find any
clean way to keep the old latching interface for debugging. So I tend
to agree that it would be better to remove the latching from the lock
manager entirely. Much of the old latching logic is implemented in the
Lockable callbacks in BasePage, and having two separate latch
implementations feels a bit awkward and, as you said, could be
difficult to maintain.

> I understand that having the latches in the lock manager helped
> finding deadlocks that included latches, but given that this kind of
> deadlocks is due to a programming error and not due to user level
> deadlocks caused by SQL statements it is a high price in terms of
> performance to include all latches in the lock manager. This type of
> deadlocks is most likely to be seen by developers (hopefully) who do
> changes to the code.

So what you basically say is that deadlocks caused by locks alone are
(most often) caused by problems in the applications, and deadlocks
involving latches are always caused by internal Derby
errors. Therefore, users should never have to debug deadlocks
involving latches. Given that a deadlock is reported as a possible
deadlock involving latches, a developer equipped with a repro should
have enough clues to be able to instrument/trace the code to find the
cause. It sounds like an acceptable cost to me when held against the
performance impact. But then I have never debugged a deadlock in the
B-trees...

> A simple approach to help discovering the cause
> of a deadlock would be to introduce a timeout when waiting for a latch
> and print this to the log file (I think you suggested that in one of
> your earlier emails).

Yes, I am planning to post a followup patch which adds timeout and a
meaningful error message once the first patch goes in. If we decide
not to keep the latch interface, I will also post a patch which cleans
up the lock manager. However, no one has commented on the first patch
yet, and I don't intend to commit it until another pair of eyes has
looked at it.

-- 
Knut Anders

Mime
View raw message