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 Mon, 16 Feb 2009 13:45:03 GMT

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

Jukka Zitting commented on JCR-1979:

I fixed the get/hasReferences methods in revision 744895. Along the same lines I also fixed
the get/hasItemState methods in revision 744911. Together these changes obsolete the entire
"Use the JCR versioning API instead of the /jcr:system/jcr:versionStorage tree to access version
information" recommendation I made earlier.

This relaxed lock scope implemented in these revisions is not troublesome, as the version
store (and any modifiable virtual item state provider) already has it's own locking mechanism
(as evidenced by the deadlock).

> 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