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

WFLYTX0001: Unable to roll back active transaction exception thrown from RTS inbound bridge

    XMLWordPrintable

Details

    Description

      This is an integration problem of REST-AT transaction inbound bridge with WFTC client.
      It's in the same way as there was for XTS txnbridge https://issues.redhat.com/browse/WFLY-9455

      The trouble is that REST-AT bridge implementation works with Narayana transaction manager. All the calls which go to the javax.transaction.TransactionManager is integrated to Narayana transaction manager backed by AtomicActions etc.
      But WildFly is fully integrated with WFTC TransactionManager as a wrapper over the Narayana one.

      The inbound bridge manages merging the REST-AT context with JTA context. On incoming REST call the InboundBridge is started and resume a transaction:
      https://github.com/jbosstm/narayana/blob/5.10.4.Final/rts/at/bridge/src/main/java/org/jboss/narayana/rest/bridge/inbound/InboundBridge.java#L104
      It's implemented by `ContainerRequestFilter` which is invoked on incoming call before the method is executed:
      https://github.com/jbosstm/narayana/blob/5.10.4.Final/rts/at/bridge/src/main/java/org/jboss/narayana/rest/bridge/inbound/InboundBridgeFilter.java#L63

      After execution is needed the transaction would be suspended again. In current time it happens for Narayana transaction but not for the WFTC transaction
      Narayana `ContainerResponseFilter` handling:

      (btw. the same is about handling of JAX-WS XTS txnbridge: https://github.com/jbosstm/narayana/blob/5.10.4.Final/txbridge/src/main/java/org/jboss/jbossts/txbridge/inbound/JaxWSTxInboundBridgeHandler.java#L114)

      Now the issue is that WFLY WFTC Transaction is not suspended on the outbound. It means the EJB still think there is an active transaction. But it's only the WFTC wrapper which wraps an empty Narayana transaction. All the real business work was done, the real transaction was suspended.
      When the call leaves the EJB there is a action which ensures no transaction leaves the EJB method (https://github.com/wildfly/wildfly/blob/19.0.0.Final/transactions/src/main/java/org/jboss/as/txn/deployment/TransactionRollbackSetupAction.java#L43). When there is some active context it's rolled-back. So WFTC Transaction rollback is called but as the WFTC holds an empty wrapper the rollback finishes with exception server log message[1].

      [1]

      ERROR [org.jboss.as.txn] (default task-1) WFLYTX0003: APPLICATION ERROR: transaction still active in request with status 0
      ERROR [org.jboss.as.txn] (default task-1) 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:105)
      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:1543)
      at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
      at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
      at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
      at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
      at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
      at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
      at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
      at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
      at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
      at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
      at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
      at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
      at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
      at java.lang.Thread.run(Thread.java:748)

      Attachments

        Issue Links

          Activity

            People

              ochaloup@redhat.com Ondrej Chaloupka (Inactive)
              ochaloup@redhat.com Ondrej Chaloupka (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: