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