[jboss-jira] [JBoss JIRA] (WFLY-1763) Escaped transactions stay associated with a HTTP request thread after they timeout
Tom Ross (JIRA)
jira-events at lists.jboss.org
Fri Jul 26 07:29:26 EDT 2013
[ https://issues.jboss.org/browse/WFLY-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom Ross updated WFLY-1763:
---------------------------
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:
{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.
was:
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.
> 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:
> {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
More information about the jboss-jira
mailing list