[
https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676686#action_12676686
]
Jukka Zitting commented on JCR-1979:
------------------------------------
I can't find any obvious deadlocked combination of locks above, but the mere
fact that two threads are concurrently inside a commit is troublesome as it
breaks one of the main invariants I used for
http://jackrabbit.apache.org/concurrency-control.html. See JCR-2000 for why
this happens and the fix for that issue.
For release management I'm going to consider this issue JCR-1979 fixed for
1.5.3 as the original problem with a concurrent commit and a getReferences call
on the version store was already solved for 1.5.3. The JCR-2000 issue will be
used to track the followup issue reported here, and I'm planning to include the
fix in a 1.5.4 release next week.
> Deadlock on concurrent read & transactional write operations
> -------------------------------------------------------------
>
> Key: JCR-1979
> URL: https://issues.apache.org/jira/browse/JCR-1979
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.5.0
> Reporter: Przemo Pakulski
> Assignee: Jukka Zitting
> Fix For: 1.5.3
>
>
> Isuue has been introduced by resolving JCR-1755 (Transaction-safe
> versioning). This fixed changed sequence of commits, but at the same time
> order of acquiring locks has been disturbed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
