[jboss-jira] [JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure

[Scott Marlow (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370956#comment-13370956 ] 

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)