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.
[EMAIL PROTECTED] wrote:
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?
