[
https://issues.jboss.org/browse/WFLY-10229?page=com.atlassian.jira.plugin...
]
David Lloyd commented on WFLY-10229:
------------------------------------
bq. David Lloyd if the transaction has been marked for rollback then Narayana won't
call before completion:
Okay, so much for that hypothesis :)
bq. Scott Marlow why is ContextTransactionManager maintaining its own transaction status
code - that is the role of the transaction manager to determine the transaction status.
You're definitely asking the wrong person. :) The answer though is, it doesn't:
it passes the status through. I think what's happening is that the wrong transaction
is being resumed during the synchronization (because the special TSR wrapper is bypassing
the WFTC API). So WFTC thinks transaction A is resumed but Narayana thinks it's B.
I'm working on a fix which involves putting this TSR ordering logic into WFTC (so that
it works even when executing in a remote transaction for example).
org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus()
should use org.wildfly.transaction.client.ContextTransactionManager.getStatus()
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: WFLY-10229
URL:
https://issues.jboss.org/browse/WFLY-10229
Project: WildFly
Issue Type: Task
Components: Transactions
Reporter: Scott Marlow
Assignee: David Lloyd
Fix For: 13.0.0.Beta1
org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.getStatus()
is currently using com.arjuna.ats.jta.TransactionManager, instead it should use
org.wildfly.transaction.client.ContextTransactionManager.getStatus().
I'm seeing a case in Hibernate ORM 5.3, where
org.wildfly.transaction.client.ContextTransactionManager.getStatus() returns 4 but
TransactionSynchronizationRegistryWrapper.getStatus() returns 1.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)