You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Przemo Pakulski (JIRA)" <ji...@apache.org> on 2009/02/13 14:35:59 UTC
[jira] Created: (JCR-1979) Deadlock on concurrent read &
transactioan write operations
Deadlock on concurrent read & transactioan 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
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.
[jira] Updated: (JCR-1979) Deadlock on concurrent read &
transactional write operations
Posted by "Przemo Pakulski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Przemo Pakulski updated JCR-1979:
---------------------------------
Summary: Deadlock on concurrent read & transactional write operations (was: Deadlock on concurrent read & transactioan write operations)
> 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
>
> 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.
[jira] Commented: (JCR-1979) Deadlock on concurrent read &
transactional write operations
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (JCR-1979) Deadlock on concurrent read &
transactional write operations
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Issue Comment Edited: (JCR-1979) Deadlock on concurrent
read & transactional write operations
Posted by "Przemo Pakulski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673249#action_12673249 ]
ppakulski edited comment on JCR-1979 at 2/13/09 5:38 AM:
---------------------------------------------------------------
Thread "http-8080-10" is executing readOnly operation, have acquired ReadLock for workspace and is waiting on ReadLock for version storage.
Thread "http-8080-18" is commiting transaction, have acquired WriteLock for version storage already and waiting on WriteLock for workspace.
was (Author: ppakulski):
Thread "http-8080-10" is executing readOnly operation, have acquired ReadLock for workspace and is waiting on ReadLock for version storage.
Thread http-8080-18 is commiting transaction, have acquired WriteLock for version storage already and waiting on WriteLock for workspace.
> 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
>
> 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.
[jira] Issue Comment Edited: (JCR-1979) Deadlock on concurrent
read & transactional write operations
Posted by "Tomek Dabrowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676666#action_12676666 ]
tomekdab edited comment on JCR-1979 at 2/25/09 6:40 AM:
---------------------------------------------------------------
Deadlock issue still exits. Please find the latest thread dump. It seems that there is an issue with method hasNodeReferences() instead of getNodeReferences() as earlier.
"http-8080-12" daemon prio=10 tid=0x0862e400 nid=0x6d48 in Object.wait() [0x42090000..0x42091ec0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x62e90220> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock)
at java.lang.Object.wait(Object.java:485)
at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown Source)
- locked <0x62e90220> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock)
at org.apache.jackrabbit.core.state.DefaultISMLocking$1.<init>(DefaultISMLocking.java:56)
at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireWriteLock(DefaultISMLocking.java:52)
at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireWriteLock(SharedItemStateManager.java:1419)
at org.apache.jackrabbit.core.state.SharedItemStateManager.access$200(SharedItemStateManager.java:116)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:547)
at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1058)
at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:156)
at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:154)
- locked <0x7a171418> (a org.apache.jackrabbit.core.TransactionContext)
at org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:324)
"http-8080-4" daemon prio=10 tid=0x088db800 nid=0x6c2b in Object.wait() [0x401ac000..0x401adec0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x5bec5790> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at java.lang.Object.wait(Object.java:485)
at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source)
- locked <0x5bec5790> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:84)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:78)
at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:44)
at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1405)
at org.apache.jackrabbit.core.state.SharedItemStateManager.hasNodeReferences(SharedItemStateManager.java:350)
at org.apache.jackrabbit.core.version.VersionItemStateProvider.hasNodeReferences(VersionItemStateProvider.java:142)
at org.apache.jackrabbit.core.state.SharedItemStateManager.hasNodeReferences(SharedItemStateManager.java:369)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.addReference(SharedItemStateManager.java:900)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.addReferences(SharedItemStateManager.java:885)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.updateReferences(SharedItemStateManager.java:868)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:560)
at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1058)
at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:156)
at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:154)
- locked <0x7a180b20> (a org.apache.jackrabbit.core.TransactionContext)
at org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:324)
was (Author: tomekdab):
Deadlock issue still exits. Please find the latest thread dump. It seems that there is an issue with methog hasNodeReferences() instead of getNodeReferences() as earlier.
"http-8080-12" daemon prio=10 tid=0x0862e400 nid=0x6d48 in Object.wait() [0x42090000..0x42091ec0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x62e90220> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock)
at java.lang.Object.wait(Object.java:485)
at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown Source)
- locked <0x62e90220> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock)
at org.apache.jackrabbit.core.state.DefaultISMLocking$1.<init>(DefaultISMLocking.java:56)
at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireWriteLock(DefaultISMLocking.java:52)
at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireWriteLock(SharedItemStateManager.java:1419)
at org.apache.jackrabbit.core.state.SharedItemStateManager.access$200(SharedItemStateManager.java:116)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:547)
at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1058)
at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:156)
at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:154)
- locked <0x7a171418> (a org.apache.jackrabbit.core.TransactionContext)
at org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:324)
"http-8080-4" daemon prio=10 tid=0x088db800 nid=0x6c2b in Object.wait() [0x401ac000..0x401adec0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x5bec5790> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at java.lang.Object.wait(Object.java:485)
at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source)
- locked <0x5bec5790> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:84)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:78)
at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:44)
at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1405)
at org.apache.jackrabbit.core.state.SharedItemStateManager.hasNodeReferences(SharedItemStateManager.java:350)
at org.apache.jackrabbit.core.version.VersionItemStateProvider.hasNodeReferences(VersionItemStateProvider.java:142)
at org.apache.jackrabbit.core.state.SharedItemStateManager.hasNodeReferences(SharedItemStateManager.java:369)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.addReference(SharedItemStateManager.java:900)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.addReferences(SharedItemStateManager.java:885)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.updateReferences(SharedItemStateManager.java:868)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:560)
at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1058)
at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:156)
at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:154)
- locked <0x7a180b20> (a org.apache.jackrabbit.core.TransactionContext)
at org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:324)
> 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.
[jira] Commented: (JCR-1979) Deadlock on concurrent read &
transactional write operations
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JCR-1979) Deadlock on concurrent read &
transactional write operations
Posted by "Przemo Pakulski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673248#action_12673248 ]
Przemo Pakulski commented on JCR-1979:
--------------------------------------
"http-8080-10" daemon prio=10 tid=0x08bb4800 nid=0x54be in Object.wait() [0x43075000..0x430771c0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x5c2cf4c0> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at java.lang.Object.wait(Object.java:485)
at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source)
- locked <0x5c2cf4c0> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:78)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:72)
at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:40)
at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1403)
at org.apache.jackrabbit.core.state.SharedItemStateManager.getNodeReferences(SharedItemStateManager.java:317)
at org.apache.jackrabbit.core.version.VersionItemStateProvider.getNodeReferences(VersionItemStateProvider.java:135)
at org.apache.jackrabbit.core.state.SharedItemStateManager.getNodeReferences(SharedItemStateManager.java:329)
at org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeReferences(LocalItemStateManager.java:202)
at org.apache.jackrabbit.core.state.XAItemStateManager.getReferences(XAItemStateManager.java:358)
at org.apache.jackrabbit.core.state.XAItemStateManager.hasNodeReferences(XAItemStateManager.java:321)
at org.apache.jackrabbit.core.state.SessionItemStateManager.hasNodeReferences(SessionItemStateManager.java:222)
at org.apache.jackrabbit.core.NodeImpl.getReferences(NodeImpl.java:4639)
at org.apache.jackrabbit.core.NodeImpl.getReferences(NodeImpl.java:2890)
"http-8080-18" daemon prio=10 tid=0x08691c00 nid=0x54d0 in Object.wait() [0x41a6c000..0x41a6dec0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x5f1e49a0> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock)
at java.lang.Object.wait(Object.java:485)
at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown Source)
- locked <0x5f1e49a0> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock)
at org.apache.jackrabbit.core.state.DefaultISMLocking$1.<init>(DefaultISMLocking.java:51)
at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireWriteLock(DefaultISMLocking.java:48)
at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireWriteLock(SharedItemStateManager.java:1417)
at org.apache.jackrabbit.core.state.SharedItemStateManager.access$200(SharedItemStateManager.java:116)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:545)
at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1056)
at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:149)
at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:138)
- locked <0x72252158> (a org.apache.jackrabbit.core.TransactionContext)
at org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:324)
> 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
>
> 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.
[jira] Commented: (JCR-1979) Deadlock on concurrent read &
transactional write operations
Posted by "Tomek Dabrowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676666#action_12676666 ]
Tomek Dabrowski commented on JCR-1979:
--------------------------------------
Deadlock issue still exits. Please find the latest thread dump. It seems that there is an issue with methog hasNodeReferences() instead of getNodeReferences() as earlier.
"http-8080-12" daemon prio=10 tid=0x0862e400 nid=0x6d48 in Object.wait() [0x42090000..0x42091ec0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x62e90220> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock)
at java.lang.Object.wait(Object.java:485)
at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown Source)
- locked <0x62e90220> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock)
at org.apache.jackrabbit.core.state.DefaultISMLocking$1.<init>(DefaultISMLocking.java:56)
at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireWriteLock(DefaultISMLocking.java:52)
at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireWriteLock(SharedItemStateManager.java:1419)
at org.apache.jackrabbit.core.state.SharedItemStateManager.access$200(SharedItemStateManager.java:116)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:547)
at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1058)
at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:156)
at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:154)
- locked <0x7a171418> (a org.apache.jackrabbit.core.TransactionContext)
at org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:324)
"http-8080-4" daemon prio=10 tid=0x088db800 nid=0x6c2b in Object.wait() [0x401ac000..0x401adec0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x5bec5790> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at java.lang.Object.wait(Object.java:485)
at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source)
- locked <0x5bec5790> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:84)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:78)
at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:44)
at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1405)
at org.apache.jackrabbit.core.state.SharedItemStateManager.hasNodeReferences(SharedItemStateManager.java:350)
at org.apache.jackrabbit.core.version.VersionItemStateProvider.hasNodeReferences(VersionItemStateProvider.java:142)
at org.apache.jackrabbit.core.state.SharedItemStateManager.hasNodeReferences(SharedItemStateManager.java:369)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.addReference(SharedItemStateManager.java:900)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.addReferences(SharedItemStateManager.java:885)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.updateReferences(SharedItemStateManager.java:868)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:560)
at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1058)
at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:156)
at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:154)
- locked <0x7a180b20> (a org.apache.jackrabbit.core.TransactionContext)
at org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:324)
> 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.
[jira] Resolved: (JCR-1979) Deadlock on concurrent read &
transactional write operations
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting resolved JCR-1979.
--------------------------------
Resolution: Fixed
Merged to the 1.5 branch in revision 744916.
I've scheduled a massively parallel randomized test run (now including getReferences() calls on version nodes) for tonight. Przemo, can you check the fix on your side and perhaps run some of your test cases on it?
> 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.
[jira] Issue Comment Edited: (JCR-1979) Deadlock on concurrent
read & transactional write operations
Posted by "Tomek Dabrowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676677#action_12676677 ]
tomekdab edited comment on JCR-1979 at 2/25/09 7:19 AM:
---------------------------------------------------------------
I forgot to add that there few more threads waiting for readLock (session create & session logout operations). Here are the related thread dumps:
"http-8080-40" daemon prio=10 tid=0x0892e400 nid=0x6ddb in Object.wait() [0x40ed8000..0x40ed9fc0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x5bec5790> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at java.lang.Object.wait(Object.java:485)
at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source)
- locked <0x5bec5790> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:84)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:78)
at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:44)
at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1405)
at org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:253)
at org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:93)
at org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:158)
- locked <0xb30f9538> (a org.apache.jackrabbit.core.state.XAItemStateManager)
at org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:253)
at org.apache.jackrabbit.core.version.XAVersionManager.<init>(XAVersionManager.java:107)
at org.apache.jackrabbit.core.XASessionImpl.createVersionManager(XASessionImpl.java:168)
at org.apache.jackrabbit.core.SessionImpl.<init>(SessionImpl.java:281)
at org.apache.jackrabbit.core.SessionImpl.<init>(SessionImpl.java:249)
at org.apache.jackrabbit.core.XASessionImpl.<init>(XASessionImpl.java:98)
at org.apache.jackrabbit.core.RepositoryImpl.createSessionInstance(RepositoryImpl.java:1497)
at org.apache.jackrabbit.core.RepositoryImpl.createSession(RepositoryImpl.java:984)
at org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1399)
"http-8080-38" daemon prio=10 tid=0x0842bc00 nid=0x6dd6 in Object.wait() [0x407e3000..0x407e4140]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x62e90210> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at java.lang.Object.wait(Object.java:485)
at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source)
- locked <0x62e90210> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:84)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:78)
at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:44)
at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1405)
at org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedItemStateManager.java:286)
at org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemStateManager.java:295)
at org.apache.jackrabbit.core.CachingHierarchyManager.stateDiscarded(CachingHierarchyManager.java:350)
at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateDiscarded(StateChangeDispatcher.java:107)
at org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:353)
at org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:323)
at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1148)
- locked <0x6fa5b8d0> (a org.apache.jackrabbit.core.XASessionImpl)
at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:403)
was (Author: tomekdab):
I forgot to add that there few more threads waiting for readLock (session login & logout operations). Here are the related thread dumps:
"http-8080-40" daemon prio=10 tid=0x0892e400 nid=0x6ddb in Object.wait() [0x40ed8000..0x40ed9fc0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x5bec5790> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at java.lang.Object.wait(Object.java:485)
at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source)
- locked <0x5bec5790> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:84)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:78)
at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:44)
at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1405)
at org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:253)
at org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:93)
at org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:158)
- locked <0xb30f9538> (a org.apache.jackrabbit.core.state.XAItemStateManager)
at org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:253)
at org.apache.jackrabbit.core.version.XAVersionManager.<init>(XAVersionManager.java:107)
at org.apache.jackrabbit.core.XASessionImpl.createVersionManager(XASessionImpl.java:168)
at org.apache.jackrabbit.core.SessionImpl.<init>(SessionImpl.java:281)
at org.apache.jackrabbit.core.SessionImpl.<init>(SessionImpl.java:249)
at org.apache.jackrabbit.core.XASessionImpl.<init>(XASessionImpl.java:98)
at org.apache.jackrabbit.core.RepositoryImpl.createSessionInstance(RepositoryImpl.java:1497)
at org.apache.jackrabbit.core.RepositoryImpl.createSession(RepositoryImpl.java:984)
at org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1399)
"http-8080-38" daemon prio=10 tid=0x0842bc00 nid=0x6dd6 in Object.wait() [0x407e3000..0x407e4140]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x62e90210> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at java.lang.Object.wait(Object.java:485)
at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source)
- locked <0x62e90210> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:84)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:78)
at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:44)
at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1405)
at org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedItemStateManager.java:286)
at org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemStateManager.java:295)
at org.apache.jackrabbit.core.CachingHierarchyManager.stateDiscarded(CachingHierarchyManager.java:350)
at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateDiscarded(StateChangeDispatcher.java:107)
at org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:353)
at org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:323)
at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1148)
- locked <0x6fa5b8d0> (a org.apache.jackrabbit.core.XASessionImpl)
at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:403)
> 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.
[jira] Commented: (JCR-1979) Deadlock on concurrent read &
transactional write operations
Posted by "Przemo Pakulski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673249#action_12673249 ]
Przemo Pakulski commented on JCR-1979:
--------------------------------------
Thread "http-8080-10" is executing readOnly operation, have acquired ReadLock for workspace and is waiting on ReadLock for version storage.
Thread http-8080-18 is commiting transaction, have acquired WriteLock for version storage already and waiting on WriteLock for workspace.
> 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
>
> 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.
[jira] Commented: (JCR-1979) Deadlock on concurrent read &
transactional write operations
Posted by "Tomek Dabrowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676677#action_12676677 ]
Tomek Dabrowski commented on JCR-1979:
--------------------------------------
I forgot to add that there few more threads waiting for readLock (session login & logout operations). Here are the related thread dumps:
"http-8080-40" daemon prio=10 tid=0x0892e400 nid=0x6ddb in Object.wait() [0x40ed8000..0x40ed9fc0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x5bec5790> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at java.lang.Object.wait(Object.java:485)
at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source)
- locked <0x5bec5790> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:84)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:78)
at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:44)
at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1405)
at org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:253)
at org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:93)
at org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:158)
- locked <0xb30f9538> (a org.apache.jackrabbit.core.state.XAItemStateManager)
at org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:253)
at org.apache.jackrabbit.core.version.XAVersionManager.<init>(XAVersionManager.java:107)
at org.apache.jackrabbit.core.XASessionImpl.createVersionManager(XASessionImpl.java:168)
at org.apache.jackrabbit.core.SessionImpl.<init>(SessionImpl.java:281)
at org.apache.jackrabbit.core.SessionImpl.<init>(SessionImpl.java:249)
at org.apache.jackrabbit.core.XASessionImpl.<init>(XASessionImpl.java:98)
at org.apache.jackrabbit.core.RepositoryImpl.createSessionInstance(RepositoryImpl.java:1497)
at org.apache.jackrabbit.core.RepositoryImpl.createSession(RepositoryImpl.java:984)
at org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1399)
"http-8080-38" daemon prio=10 tid=0x0842bc00 nid=0x6dd6 in Object.wait() [0x407e3000..0x407e4140]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x62e90210> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at java.lang.Object.wait(Object.java:485)
at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source)
- locked <0x62e90210> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:84)
at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:78)
at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:44)
at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1405)
at org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedItemStateManager.java:286)
at org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemStateManager.java:295)
at org.apache.jackrabbit.core.CachingHierarchyManager.stateDiscarded(CachingHierarchyManager.java:350)
at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateDiscarded(StateChangeDispatcher.java:107)
at org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:353)
at org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:323)
at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1148)
- locked <0x6fa5b8d0> (a org.apache.jackrabbit.core.XASessionImpl)
at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:403)
> 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.
[jira] Commented: (JCR-1979) Deadlock on concurrent read &
transactional write operations
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676676#action_12676676 ]
Jukka Zitting commented on JCR-1979:
------------------------------------
The deadlock seems to be a bit different, here we have two threads trying to commit a transaction at the same time.
This should not be possible as all transactions will first acquire a write lock on the shared version store before proceeding to XAItemStateManager.prepare. I'll try to find out how the above could have happened.
> 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.