Olav Sandstaa <[EMAIL PROTECTED]> writes: > Knut Anders Hatlen wrote: >> Mike Matrigali <[EMAIL PROTECTED]> 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
