[
https://issues.apache.org/jira/browse/JCR-2554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845355#action_12845355
]
Robert Sauer commented on JCR-2554:
-----------------------------------
My interpretation is that it implements the WriterPreference part of the
WriterPreferenceReadWriteLock super class. Essentially allowing no new readers
as long as there is someone waiting to write (see JavaDoc of
WriterPreferenceReadWriteLock).
I would suggest to stay as close as possible to the super implementation of
overridden methods. It's part of both allowWriter() implementations for
ReentrantWriterPreferenceReadWriteLock as well as WriterPreferenceReadWriteLock.
Practical side effect should be that TX-finalization will tend to be quicker in
a mixed read/write scenario as parallel readers will not be able to starve 2PC
requests.
> Deadlock inside XASession on Weblogic
> -------------------------------------
>
> Key: JCR-2554
> URL: https://issues.apache.org/jira/browse/JCR-2554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.6.1, 2.0.0
> Environment: Weblogic 9.2
> Reporter: Robert Sauer
> Assignee: Claus Köll
> Priority: Critical
> Fix For: 1.6.2, 2.1.0
>
> Attachments: ConcurrentReaders.java,
> jr-core-xid-aware-ism-locking1.patch, Xid.patch, Xid_v2 + SynchronizedRef for
> markedXid.jpg, Xid_v2 deadlock.jpg, Xid_v2.patch, Xid_v3.patch, Xid_v4.patch
>
>
> In one of our client deployments on WebLogic 9.2 we observed JackRabbit
> sessions going stale in a load test. This was observed against release 1.6.1
> (to which we migrated due to concurrency related issues JCR-2081 and
> JCR-2237). Same effect with 2.0.0.
>
> I could finally reproduce this issue locally. And it seems to boil down to
> WLS invoking the sequence of <prepare> ... <release> ... <commit> on one XA
> session from multiple threads, as it seems breaking assumptions of the
> thread-bound java.util.concurrent-RWLock based DefaultISMLocking class.
> Effectively the setActiveXid(..) method on DefaultISMLocking$RWLock fails as
> the old active XID was not yet cleared. With the result of more and more
> sessions deadlocking in below's invocation stack.
> {code}
> "[ACTIVE] ExecuteThread: '27' for queue: 'weblogic.kernel.Default
> (self-tuning)'" daemon prio=1 tid=0x33fc3ec0 nid=0x2324 in Object.wait()
> [0x2156a000..0x2156beb0] at java.lang.Object.wait(Native Method) - waiting on
> <0x68a54698> (a
> EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at
> java.lang.Object.wait(Object.java:474) at
> EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown
> Source) - locked <0x68a54698> (a
> EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at
> org.apache.jackrabbit.core.state.DefaultISMLocking$1.<init>(DefaultISMLocking.java:64)
> at
> org.apache.jackrabbit.core.state.DefaultISMLocking.acquireWriteLock(DefaultISMLocking.java:61)
> at
> org.apache.jackrabbit.core.version.AbstractVersionManager.acquireWriteLock(AbstractVersionManager.java:146)
> at
> org.apache.jackrabbit.core.version.XAVersionManager$1.prepare(XAVersionManager.java:562)
> at
> org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:154)
> - locked <0x6dc2ad88> (a org.apache.jackrabbit.core.TransactionContext) at
> org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:331) at
> org.apache.jackrabbit.jca.TransactionBoundXAResource.prepare(TransactionBoundXAResource.java:68)
> at
> weblogic.connector.security.layer.AdapterLayer.prepare(AdapterLayer.java:397)
> at
> weblogic.connector.transaction.outbound.XAWrapper.prepare(XAWrapper.java:297)
> at
> weblogic.transaction.internal.XAServerResourceInfo.prepare(XAServerResourceInfo.java:1276)
> at
> weblogic.transaction.internal.XAServerResourceInfo.prepare(XAServerResourceInfo.java:499)
> at
> weblogic.transaction.internal.ServerSCInfo$1.execute(ServerSCInfo.java:335)
> at weblogic.kernel.Kernel.executeIfIdle(Kernel.java:243) at
> weblogic.transaction.internal.ServerSCInfo.startPrepare(ServerSCInfo.java:326)
> at
> weblogic.transaction.internal.ServerTransactionImpl.localPrepare(ServerTransactionImpl.java:2516)
> at
> weblogic.transaction.internal.ServerTransactionImpl.globalPrepare(ServerTransactionImpl.java:2211)
> at
> weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:266)
> at
> weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:227)
> at
> weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:283)
> at
> org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1028)
> at
> org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at
> org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
