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] Reopened: (JCR-2000) Deadlock on concurrent commits
Date Thu, 05 Mar 2009 18:17:56 GMT

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


Mime
View raw message