jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-3924) Fix database-level row deadlock during bulk updates in RDB
Date Thu, 28 Jan 2016 08:28:40 GMT

    [ https://issues.apache.org/jira/browse/OAK-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15121014#comment-15121014
] 

Thomas Mueller edited comment on OAK-3924 at 1/28/16 8:28 AM:
--------------------------------------------------------------

As Tomek wrote above: To avoid deadlocks, it is usually sufficient to sort the data. For example,
if you session 1 updates "c", "a", and "b", and session 2 updates "b", "a", and "d", then
it's best if both sessions first sorts the data (for example alphabetically). Unsorted, it
can result in a deadlock because if "a" is already locked by session 1 and "b" is already
locked by session 2 before session 1 can get a lock on "b" and session 2 can get a lock on
"a". If session 1 locks in order "a", "b", "c", and session 2 locks in order "a", "b", "d",
then no deadlock occurs. See also [StackOverflow|http://stackoverflow.com/questions/7428578/proper-design-to-avoid-oracle-deadlocks].
Ordering only works if you know the whole list before starting the transaction, but this is
what we do, right?



was (Author: tmueller):
To avoid deadlocks, it is usually sufficient to sort the data. For example, if you session
1 updates "c", "a", and "b", and session 2 updates "b", "a", and "d", then it's best if both
sessions first sorts the data (for example alphabetically). Unsorted, it can result in a deadlock
because if "a" is already locked by session 1 and "b" is already locked by session 2 before
session 1 can get a lock on "b" and session 2 can get a lock on "a". If session 1 locks in
order "a", "b", "c", and session 2 locks in order "a", "b", "d", then no deadlock occurs.
See also [StackOverflow|http://stackoverflow.com/questions/7428578/proper-design-to-avoid-oracle-deadlocks].
Ordering only works if you know the whole list before starting the transaction, but this is
what we do, right?

> Fix database-level row deadlock during bulk updates in RDB
> ----------------------------------------------------------
>
>                 Key: OAK-3924
>                 URL: https://issues.apache.org/jira/browse/OAK-3924
>             Project: Jackrabbit Oak
>          Issue Type: Sub-task
>          Components: rdbmk
>            Reporter: Tomek Rękawek
>            Priority: Critical
>             Fix For: 1.4
>
>         Attachments: OAK-3924.patch
>
>
> It seems that the new bulk createOrUpdate() implementation in RDB is prone for the deadlocks.
It isn't a bug in the Oak code, but rather something related to the database implementations.
The bug can be observed if we have multiple  simultaneous bulk updates and some of the rows
repeat among them. The attached patch contains an unit test {{testConcurrentWithConflict}}
presenting the issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message