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 Tue, 28 Nov 2006 00:39:03 GMT


Daniel John Debrunner wrote:
> 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'm not so sure. If it's simpler to keep page latching at the page 
> level, then it would be better to remove the added complexity from the 
> lock manager. What's the current state of IDEs/debuggers tracking down 
> java synchronization deadlocks? Seems a better place to solve the problem.
And also does it help track down a deadlock that is half java 
synchonization and half derby lock wait?
> 
> Dan.
> 
> 
> 


Mime
View raw message