[
https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin....
]
Scott Marlow commented on WFLY-5319:
------------------------------------
Adding some more notes on this:
Note 1:
{quote}
I noticed that [1]
TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest is now failing on
the CI machine but not locally for me. I saved a copy of the test output [1], so that we
could look at the possible causes.
1. Reaper thread throws a IllegalMonitorStateException from
org.jboss.as.ejb3.tx.OwnableReentrantLock.unlock(). I'm not sure exactly why but
I'm wondering if TransactionSynchronizationRegistry.getTransactionKey() returned null
to StatefulSessionSynchronizationInterceptor.getLockOwner(), which causes the current
"thread" to be used in the call to OwnableReentrantLock.unlock(). This happens
at "21:06:34,782"
2. An exception is thrown in the application thread and the EJB container ends the
transaction ("javax.ejb.EJBTransactionRolledbackException: Transaction rolled
back" is thrown since the transaction is already rolled back).
3. Application thread fails unit test with "entity manager should not of been closed
by the reaper thread" error. From the log, the entity manager is closed from the
reaper thread at "21:06:34,782". The unit test failure is reported from the
application thread at "21:06:34,800".
The test failure is clearly caused by (3) but that might reflect that the application
thread was first disassociated from the active transaction and then the reaper thread ran
the JPA container afterCompletion() synchronization callback (which is now legal but not
expected IMO).
{quote}
Note 2, which refers back to note 1:
{quote}
I looked a little closer at (2) and the exception call stack points to the code at
org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98) which is:
else if (txStatus == Status.STATUS_ROLLEDBACK) {
tm.rollback();
throw EjbLogger.ROOT_LOGGER.transactionAlreadyRolledBack(tx);
}
I don't really have any questions about (2), that is how the EJB container informs the
application of the failure.
For (1), I am curious if TransactionSynchronizationRegistry.getTransactionKey() can be
expected to return null when the reaper thread calls the afterCompletion sync callback?
For (3), it seems likely that the application thread was first disassociated from the
transaction and then the JPA afterCompletion was invoked, which (properly) closed the
container managed entity manager. If this is what happened, then TxTimeoutTestCase needs
to check for different conditions to detect (potential) concurrency failure.
{quote}
fix
org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest
failure
---------------------------------------------------------------------------------------------------------------------------------------------
Key: WFLY-5319
URL:
https://issues.jboss.org/browse/WFLY-5319
Project: WildFly
Issue Type: Feature Request
Components: JPA / Hibernate
Reporter: Scott Marlow
Assignee: Scott Marlow
https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)