Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-1763

Escaped transactions stay associated with a HTTP request thread after they timeout

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 8.0.0.CR1
    • None
    • Transactions
    • None

    Description

      When a transaction times out during execution of HTTP request and an inadequate error handling lets it escape the next HTTP request gets exception:

      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) 
      

      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.

      Attachments

        Activity

          People

            sdouglas1@redhat.com Stuart Douglas
            rhn-support-toross Tom Ross
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: