[
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)
