Escaped transactions stay associated with a HTTP request thread after they timeout ---------------------------------------------------------------------------------- Key: WFLY-1763 URL: https://issues.jboss.org/browse/WFLY-1763 Project: WildFly Issue Type: Bug Security Level: Public(Everyone can see) Components: Transactions Environment: JBoss EAP 6.1 Reporter: Tom Ross Assignee: Stuart Douglas When a transaction times out during execution of HTTP request and an inadequate error handling lets it escape the next HTTP request gets exception: {noformat} 20130528,17:20:05,561 ERROR [CheckupAction] DB-HIBERNATE: ERROR: xx.yyy.zzz.utils.TransactionAdapterSDB$TransactionSDBException: java.lang.RuntimeException: javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState - ARJUNA016051: thread is already associated with a transaction! at xx.yyy.zzz.utils.TransactionAdapterSDB.begin(TransactionAdapterSDB.java:85) [WebPortalCore.jar:] at xx.yyy.apps.crmtrk.web.component.HibernateSessionHandler.getHBS(HibernateSessionHandler.java:30) [WebPortalCore.jar:] at xx.yyy.apps.crmtrk.web.action.HibernateAction.getHBS(HibernateAction.java:91) [WebPortalCore.jar:] at xx.yyy.apps.crmtrk.web.action.CheckupAction.execute(CheckupAction.java:643) [classes:] at com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:283) [xwork-1.0.5.jar:] at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:166) [xwork-1.0.5.jar:] at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:35) [xwork-1.0.5.jar:] at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:164) [xwork-1.0.5.jar:] at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:35) [xwork-1.0.5.jar:] at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:164) [xwork-1.0.5.jar:] at xx.yyy.apps.crmtrk.web.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:80) {noformat} This does not happen to transactions that did not timed out. They seemed to be cleaned up. This is due to the TransactionRollbackSetupAction class that supposed to make sure that there are not transaction leaks in EE request. There is a method checkTransactionStatus() that performs a check on an escaped transaction and does a rollback() if it finds a transaction with following status: {noformat} switch (status) { case Status.STATUS_ACTIVE: case Status.STATUS_COMMITTING: case Status.STATUS_MARKED_ROLLBACK: case Status.STATUS_PREPARING: case Status.STATUS_ROLLING_BACK: case Status.STATUS_PREPARED: try { TransactionLogger.ROOT_LOGGER.transactionStillOpen(status); tm.rollback(); } catch (Exception ex) { TransactionLogger.ROOT_LOGGER.unableToRollBack(ex); } } {noformat} The status of a timed out transaction is STATUS_ROLLEDBACK which explains why it escapes this cleanup attempt.