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] Updated: (DERBY-4080) Possible deadlock between locks and latches in BTreeController.compareRowsForInsert()
Date Thu, 03 Jun 2010 09:47:58 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Knut Anders Hatlen updated DERBY-4080:
--------------------------------------

    Issue & fix info: [Repro attached]

> 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
>         Attachments: repro.sql
>
>
> 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 dea!
 dlock).
> 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