This from mail thread on transactional mailing list: There is definitely a bug in EJBR. These two at least look wrong by inspection: https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/remote/protocol/versionone/XidTransactionPrepareTask.java#L100 https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/remote/protocol/versionone/XidTransactionCommitTask.java#L68 The way they are implemented means that when the transaction manager calls commit/prepare on an Xid if there is no transaction at the remote side EJBR just ignores the problem whereas it needs to return an XA error so the TM knows about it. You could simulate this with a test case that gets hold of the EJBR XAResource and invokes: xar.prepare(dummyXid) and does not get back XAER_NOTA That explains how the root transaction can prepare/commit without error as we can see here: 2016-09-12 16:04:02,303 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=State{transactionID=org.jboss.ejb.client.XidTransactionID@303ce194, suspended=false, participantCnt=0}}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b 2016-09-12 16:04:02,364 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=null}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b Both those lines I indicated above have debug statements but they should be ERROR and return appropriate XA exceptions. What it does not explain is why the transaction is initially imported 45 minutes later. I guess it is stuck in some EJB processing queue.
I used test from crashrec testsuite for reproducing the issue mvn clean verify -Djboss.dist=$JBOSS_HOME -Dtest=TxPropagationEJbXAResourceTestCase -Deap6 -DfailIfNoTests=false Non exiting transaction is still silently ignored -> Reopened.