db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Created: (DERBY-4080) Possible deadlock between locks and latches in BTreeController.compareRowsForInsert()
Date Tue, 03 Mar 2009 10:34:56 GMT
Possible deadlock between locks and latches in BTreeController.compareRowsForInsert()
-------------------------------------------------------------------------------------

                 Key: DERBY-4080
                 URL: https://issues.apache.org/jira/browse/DERBY-4080
             Project: Derby
          Issue Type: Bug
          Components: Store
    Affects Versions: 10.4.2.0
            Reporter: Knut Anders Hatlen


It looks like BTreeController.compareRowsForInsert(), which is used to check for duplicates
in a unique nullable index, can run into a deadlock which involves both locks and latches.

Here's what I think can happen:

comparePreviousRecord() (or compareNextRecord()) holds a latch on the index page where a new
row is about to be inserted, and needs to check if there's a duplicate on one of the adjacent
rows. Because the row is near a page boundary, this check moves to another index page, while
still holding the latch on the original index page. Then compareRowsForInsert() is called,
which tries to get an update lock on the existing row. If it has to wait for the update lock,
the latch on the current page is released, but the latch on the original index page is kept.
This means that the transaction is holding a latch while it is waiting for a lock, which means
that it is blocking all access to that page until it has been granted the lock. If some other
transaction that is holding a conflicting lock on the row later needs to latch the index page,
those two transactions run into a deadlock and the one that's waiting for the lock will eventually
time out (but it will not be reported as a deadlo
 ck).

If compareRowsForInsert() releases all latches when it needs to wait for a lock, the deadlock
is prevented, and both of the transactions may be able to complete without timing out.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message