[jboss-jira] [JBoss JIRA] (WFLY-1763) Escaped transactions stay associated with a HTTP request thread after they timeout

[Tom Ross (JIRA)]

Tom Ross created WFLY-1763:
------------------------------

             Summary: 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
          Components: Transactions
         Environment: JBoss EAP 6.1
            Reporter: Tom Ross
            Assignee: jaikiran pai


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: 


	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);
                    }
            }

The status of a timed out transaction is STATUS_ROLLEDBACK which explains why it escapes this cleanup attempt.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira