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-1979) Deadlock on concurrent read & transactional write operations
Date Wed, 25 Feb 2009 16:03:01 GMT

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

View raw message