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 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. 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).
Olav
