[
https://issues.apache.org/jira/browse/DERBY-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-4080:
----------------------------------
Affects Version/s: 10.11.0.0
ran script against trunk and it gets lock timeout at end.
> 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, 10.11.0.0
> Reporter: Knut Anders Hatlen
> Labels: derby_triage10_5_2, derby_triage10_9
> 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 deadlock).
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
