[jboss-jira] [JBoss JIRA] (WFLY-7196) The outcome of xa_commit call on non exiting transaction is silently ignored

[Johnathon Lee (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnathon Lee updated WFLY-7196:
--------------------------------


> The outcome of xa_commit call on non exiting transaction is silently ignored
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-7196
>                 URL: https://issues.jboss.org/browse/WFLY-7196
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>            Reporter: Tom Ross
>            Assignee: Flavia Rainone
>
> This is from mail thread on transactional mailing list:
> {noformat}
> 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 at 18d6826a, nodeName='svc-2-presentation', state=State{transactionID=org.jboss.ejb.client.XidTransactionID at 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 at 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 at 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 at 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.
> What I think needs curing first is the data integrity issue (i.e. silently ignoring if there is no imported transaction) in the EJB remoting transport. That should be relatively easy as EJBR can just return appropriate errors when it can't find the imported transaction. This part should be tackled urgently.
> After that the strange error where the import is processed late should be tackled but I am not familiar enough with the EJB remoting async architecture to suggest how to proceed with that.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)