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

[Stuart Douglas (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-1763:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> 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.

--
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