Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Mon, 7 Feb 2011 10:25:30 +0000 (UTC)
From: "Dominique Pfister (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: 
 <777893520.3566.1297074330875.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <2119177386.3536.1297073490690.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Commented: (JCR-2881) Deadlock on version operations in a
 clustered environment
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Dominique Pfister commented on JCR-2881:
----------------------------------------

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