jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2000) Deadlock on concurrent commits
Date Wed, 04 Mar 2009 10:45:56 GMT

    [ https://issues.apache.org/jira/browse/JCR-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678683#action_12678683

Jukka Zitting commented on JCR-2000:

The thread deaths I saw were caused by the RandomOperationTest class killing them. At least
in a few cases the threads were still holding on locks, which made the test block indefinitely
in the cleanup phase after all test threads had been killed.

Why do we need the thread killing in the first place? A normal join() call with no timeout
should be fine enough. If there's a deadlock, then a manually generated thread dump is much
more accurate (it contains all the locks held) than the stack traces that the test case now

> Hmm, I understand, but the above mentioned test works just fine in the 1.4 branch.

The proposed change here extends the scope of the versioning lock acquired in a transaction
commit, which makes this deadlock (A: commit() -> versioning lock -> workspace lock;
B: save() -> workspace lock -> versioning lock) more likely to happen, but the deadlock
scenario already existed before, it probably just was never triggered due to lucky timing.

> Deadlock on concurrent commits
> ------------------------------
>                 Key: JCR-2000
>                 URL: https://issues.apache.org/jira/browse/JCR-2000
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, transactions
>    Affects Versions: 1.5.3
>            Reporter: Jukka Zitting
>            Assignee: Jukka Zitting
>             Fix For: 1.5.4
>         Attachments: JCR-2000.patch, JCR-2000.patch
> As reported in the followup to JCR-1979, there's a case where two transactions may be
concurrently inside a commit. This is bad as it breaks the main assumption in http://jackrabbit.apache.org/concurrency-control.html
about all transactions first acquiring the versioning write lock.
> Looking deeper into this I find that the versioning write lock is only acquired if the
transaction being committed contains versioning operations. This is incorrect as all transactions
in any case need to access the version store when checking for references.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message