[
https://issues.apache.org/jira/browse/JCR-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting reopened JCR-2000:
--------------------------------
One more thing, detected in a test run I left for the night. The
VersionItemStateProvider.hasNodeReferences() call inside the scope of a
workspace lock conflicts with the versioning lock held by another thread. The
conflict can be seen in the following thread dump:
HOLDS WORKSPACE LOCK, WAITS FOR VERSIONING LOCK
"Thread-577" prio=10 tid=0x0859ac00 nid=0x6e86 in Object.wait()
[0xa487a000..0xa487af20]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0xad082b20> (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 <0xad082b20> (a
EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at
org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:86)
at
org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:80)
at
org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:44)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1403)
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:898)
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.addReferences(SharedItemStateManager.java:883)
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.updateReferences(SharedItemStateManager.java:866)
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:560)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1056)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1086)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:337)
at
org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:347)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:312)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:313)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1105)
- locked <0xb0cc9e00> (a org.apache.jackrabbit.core.XASessionImpl)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:846)
at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:3340)
at
org.apache.jackrabbit.core.ConcurrentVersioningWithTransactionsTest$2.execute(ConcurrentVersioningWithTransactionsTest.java:119)
at
org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:164)
at java.lang.Thread.run(Thread.java:619)
HOLDS VERSIONING LOCK, WAITS FOR WORKSPACE LOCK
"Thread-571" prio=10 tid=0xa7991400 nid=0x6e80 in Object.wait()
[0xa4ddb000..0xa4ddbe20]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0xad082c28> (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 <0xad082c28> (a
EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock)
at
org.apache.jackrabbit.core.state.DefaultISMLocking$1.<init>(DefaultISMLocking.java:55)
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:1056)
at
org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:156)
at
org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:154)
- locked <0xb0f06868> (a org.apache.jackrabbit.core.TransactionContext)
at
org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:324)
at
org.apache.jackrabbit.core.UserTransactionImpl.commit(UserTransactionImpl.java:121)
at
org.apache.jackrabbit.core.ConcurrentVersioningWithTransactionsTest$2.execute(ConcurrentVersioningWithTransactionsTest.java:117)
at
org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:164)
at java.lang.Thread.run(Thread.java:619)
The VersionItemStateManager already avoids this conflict in the way it
overrides the setNodeReferences() method, but it should do the same also for
the get/hasNodeReferences() methods that are invoked by SharedItemStateManager
when persisting normal workspace content.
> Deadlock on concurrent commits
> ------------------------------
>
> Key: JCR-2000
> URL: https://issues.apache.org/jira/browse/JCR-2000
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.5.3
> Reporter: Jukka Zitting
> Assignee: Jukka Zitting
> Fix For: 1.5.4
>
> Attachments: JCR-2000.patch, JCR-2000.patch, search-on-sism.patch,
> thread-join.patch
>
>
> As reported in the followup to JCR-1979, there's a case where two
> transactions may be concurrently inside a commit. This is bad as it breaks
> the main assumption in http://jackrabbit.apache.org/concurrency-control.html
> about all transactions first acquiring the versioning write lock.
> Looking deeper into this I find that the versioning write lock is only
> acquired if the transaction being committed contains versioning operations.
> This is incorrect as all transactions in any case need to access the version
> store when checking for references.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
