Daniel John Debrunner wrote:
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'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.
