[jboss-jira] [JBoss JIRA] (WFLY-9455) WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions

Tue Nov 21 05:06:00 EST 2017

    [ https://issues.jboss.org/browse/WFLY-9455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491940#comment-13491940 ] 

Ondra Chaloupka edited comment on WFLY-9455 at 11/21/17 5:05 AM:
-----------------------------------------------------------------

I've discussed issues I have with [~dmlloyd] and [~asoldano]. The state of the issue

The trouble is about integration of the narayana and XTS with WFTC. When call leaves ejb there is invoked handler [TransactionRollbackSetupAction|https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/deployment/TransactionRollbackSetupAction.java#L134] verifying existence of transactions. At that time the transaction should be suspended. In case of WS call where XTS txn was [imported|https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/invocation/AbstractInvocationHandler.java#L155] the suspend of the transaction is done in XTS handler. This handler is part of the Narayana code and narayana transaction is thus suspended. But WFTC stores its own notion about transaction existence and noone suspends the WFTC transaciton notion. That's the issue.

I had two approaches to the issue.

* checking the status of the existence of the narayana transaction  in the ejb handler. This would mean refresh what the WFTC knows about the underlaying transaction. As the ejb handler asks WFTC about transaction existence, refreshing the state WFTC based of the state of narayana transaction will cause WFTC returns what narayana knows about transaction status: https://github.com/ochaloup/wildfly/commit/2c55e5ac86b778f3b8bdc4227ec1553f02394eaa
** we talked with David that this is not a great approach as WFLY should not be coded directly to the underalying txn implementation machine (narayana) and WFLY should just use the WFTC
* having a XTS handler which suspends the transactions (similar what Narayana one does for narayana transaction). We need to have an WS handler which is capable to use classes from XTS, Narayana, WFTC, WS modules. But such module in WFLY does no texists. Thus idea is to create a special one with such abilities. But that's not a nice way. https://github.co/ochaloup/wildfly/commit/b7c07afecfe7f794930e9f790b669817bfe86c48
** Another investigated option is register an WS handler directly as an instance (normally WFLY registers WS handlers with name of the class and they are intialized later by WFLY reflection code). But this is not possible (discussed with Alessio) as WS needs to instantiate the WS handler itself to make handling around.

was (Author: ochaloup):
I've discussed issues I have with [~dmlloyd] and [~asoldano]. The state of the issue

The trouble is about integration of the narayana and XTS with WFTC. When call leaves ejb there is invoked handler [TransactionRollbackSetupAction|https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/deployment/TransactionRollbackSetupAction.java#L134] verifying existence of transactions. At that time the transaction should be suspended. In case of WS call where XTS txn was [imported|https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/invocation/AbstractInvocationHandler.java#L155] the suspend of the transaction is done in XTS handler. This handler is part of the Narayana code and narayana transaction is thus suspended. But WFTC stores its own notion about transaction existence and noone suspends the WFTC transaciton notion. That's the issue.

I had two approaches to the issue.

* checking the status of the existence of the narayana transaction  in the ejb handler. This would mean refresh what the WFTC knows about the underlaying transaction. As the ejb handler asks WFTC about transaction existence, refreshing the state WFTC based of the state of narayana transaction will cause WFTC returns what narayana knows about transaction status: https://github.com/ochaloup/wildfly/commit/2c55e5ac86b778f3b8bdc4227ec1553f02394eaa
** we talked with David that this is not a great approach as WFLY should not be coded directly to the underalying txn implementation machine (narayana) and WFLY should just use the WFTC
* having a XTS handler which suspends the transactions (similar what Narayana one does for narayana transaction). https://github.com/ochaloup/wildfly/commit/b7c07afecfe7f794930e9f790b669817bfe86c48

> WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-9455
>                 URL: https://issues.jboss.org/browse/WFLY-9455
>             Project: WildFly
>          Issue Type: Bug
>          Components: XTS
>    Affects Versions: 11.0.0.CR1
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>
> It happens to get exception
> {code}
> ERROR [org.jboss.as.txn] (default task-12) WFLYTX0003: APPLICATION ERROR: transaction still active in request with status 0
> ERROR [org.jboss.as.txn] (default task-12) WFLYTX0001: Unable to roll back active transaction: javax.transaction.SystemException: WFTXN0032: Rollback not allowed on imported transaction
>         at org.wildfly.transaction.client.LocalTransaction.rollbackAndDissociate(LocalTransaction.java:100)
>         at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:83)
>         at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.checkTransactionStatus(TransactionRollbackSetupAction.java:137)
>         at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.teardown(TransactionRollbackSetupAction.java:67)
>         at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1510)
>         at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>         at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>         at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>         at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
>         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
>         at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
>         at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
>         at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>         at java.lang.Thread.run(Thread.java:748)
> {code}
> when using XTS transactions bridged to JTA for EJB handling. This happens on change of integration layer for WFTC in WFLY11.
> The integration issues were already discussed as part of the JBTM-2853.
> Here I hit a trouble of having log filled with the exception mentioned above. This does not cause a functionality trouble but the log is ugly filled with ERRORs.
> The trouble seems to be caused by the fact that transaction is imported on ivocation of WS
> https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/invocation/AbstractInvocationHandler.java#L155
> but as it was suspended in the integration code before
> https://github.com/jbosstm/narayana/blob/master/txbridge/src/main/java/org/jboss/jbossts/txbridge/inbound/JaxWSTxInboundBridgeHandler.java#L118
> now the WFTC holds the notion about the transaction even on call of 
> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/deployment/TransactionRollbackSetupAction.java#L134
> and such transaction is tried to be rollback which is forbidden on WFTC for imported ones and thus at least ERROR msg is written to the log.

--
This message was sent by Atlassian JIRA
(v7.5.0#75005)