[jbossts-issues] [JBoss JIRA] (JBTM-2124) Add orphan detection for JTS interposition mode
Tom Jenkinson (JIRA)
issues at jboss.org
Fri Nov 14 11:03:31 EST 2014
[ https://issues.jboss.org/browse/JBTM-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020162#comment-13020162 ]
Tom Jenkinson commented on JBTM-2124:
-------------------------------------
Historically, the reason this is a problem is if you have two recovery managers querying the same resource manager for Xids (but because the transaction flowed from a remote server, neither of these hosted the top level coordinator) then you would not be able to apply a filter that ensured only the recovery manager where the resource manager was originally enlisted at performs a rollback as its nodeId was not in the Xid.
Now, when we developed the integration code for the EJB remoting transport as used in WidFly we had a similar issue and we developed a system whereby we can encode the subordinates node id into the bqual of the Xid. It is possible that we could use that technique when generating the Xid to enlisting XAR for JTS branches too. Pertinent code is available over here: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/jta/xa/XATxConverter.java#L171 This is where it is called from: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/subordinate/jca/SubordinateAtomicAction.java#L107
> Add orphan detection for JTS interposition mode
> -----------------------------------------------
>
> Key: JBTM-2124
> URL: https://issues.jboss.org/browse/JBTM-2124
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: Recovery
> Affects Versions: 4.17.17
> Reporter: Ondřej Chaloupka
> Assignee: Tom Jenkinson
>
> Currently orphan detection is supported for JTA, not for JTS. Please, add the suport for JTS as well.
> The following scenario for JTS causes that the orphan is left in the transaction log store and the prepared resource could held the lock till the time that it's timeouted on the side of the database/jms.
> The program flow is following (test run on EAP 6)
> enlisting jms xaresource to transaction
> sending msg to queue
> enlisting xa test resource
> preparing jms xaresource
> preparing xa test resource
> crash JVM at the end of the test XAResource.prepare()
> restart app server and recovery is run
> During recovery the jms resource is processed correctly because TM found some info in its jts logs. But such info was not saved for test xa resource. The test xa is not rollback.
> More info and discussion could be found at: https://bugzilla.redhat.com/show_bug.cgi?id=1064170
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
More information about the jbossts-issues
mailing list