[
https://issues.apache.org/jira/browse/DERBY-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-4080:
---------------------------------
Urgency: Normal
Triaged July 2, 2009: Assigning normal urgency.
> 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 dead
lock).
> 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.
