Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <362482965.1235577781836.JavaMail.jira@brutus>
Date: Wed, 25 Feb 2009 08:03:01 -0800 (PST)
From: "Jukka Zitting (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-1979) Deadlock  on concurrent read &
 transactional write operations
In-Reply-To: <1032941449.1234532159933.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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