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] Updated: (JCR-1979) Deadlock on concurrent read & transactional write operations
Date Fri, 13 Feb 2009 13:51:59 GMT

     [ https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Jukka Zitting updated JCR-1979:

    Fix Version/s: 1.5.3
         Assignee: Jukka Zitting

This is the "Use the JCR versioning API instead of the /jcr:system/jcr:versionStorage tree
to access version information" case I pointed out in  http://jackrabbit.apache.org/concurrency-control.html.
The getReferences() method seems to break this assumption when it accesses the version store
for backreferences. The getReferences() method should be made to work like the versioning
API methods when accessing the version store.

I'll look into this and try to get a fix included already in 1.5.3 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