[
https://issues.apache.org/jira/browse/JCR-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12991326#comment-12991326
]
Dominique Pfister edited comment on JCR-2881 at 2/7/11 10:26 AM:
-----------------------------------------------------------------
Solution looks as follows: when doing a cluster sync, whether it is for reading
or writing, always acquire the version manager's read lock first.
was (Author: dpfister):
Solution looks as follows: when doing a cluster sync, whether it is for
reading or writing, always acquire a the version manager's read lock first.
> Deadlock on version operations in a clustered environment
> ---------------------------------------------------------
>
> Key: JCR-2881
> URL: https://issues.apache.org/jira/browse/JCR-2881
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.2.3
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
> Attachments: jackrabbit-core-2.2.3.patch
>
>
> Version operations in a cluster may end up in a deadlock: a write operation
> in the version store will acquire the version manager's write lock (N1.VW)
> and subsequently the cluster journal's write lock (N1.JW). Another cluster
> node's write operation in some workspace will acquire the journal's write
> lock (N2.JW) and first process the journal record log: if some of these
> changes concern the version store, the version manager's read lock (N2.VR)
> has to be acquired in order to deliver them. If the first cluster node
> reaches N1.VW, and the second reaches N2.JW, we have a deadlock. The same
> scenario takes place when the second cluster node synchronizes to the latest
> journal changes and reaches N2.JR, when the first cluster node is in N1.VW.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
