[
https://issues.apache.org/jira/browse/ARIES-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14170995#comment-14170995
]
David Jencks commented on ARIES-1265:
-------------------------------------
I think this will probably have to be fixed in the geronimo txmanager, not
aries. I think we might be able to figure out how to call end(success) on the
"original" XAResource when you check out another one, but I'm less sure we
could recognize that you are starting to reuse it and end the other one and
re-join the first one.
Something else we could try is giving the connections from each pool a
different xid branch in the same global tx. We could (with a flag??) override
isSameRM for a NamedXAResource to compare the names as well as delegate to the
wrapped XAResource.
> Aries Transactions: Transaction Enlisting failing for multiple
> OracleXADataSources/Connections
> ----------------------------------------------------------------------------------------------
>
> Key: ARIES-1265
> URL: https://issues.apache.org/jira/browse/ARIES-1265
> Project: Aries
> Issue Type: Bug
> Components: Transaction
> Environment: JBoss Fuse 6.1, Apache Karaf 2.3.0, Aries Transaction
> 1.0.x, Oracle 11.2
> Reporter: Jörn Gersdorf
> Attachments: test-geronimo-tx.zip
>
>
> When using multiple Oracle XADataSources (and thus XAConnections) within the
> same global XA transaction, Apache Aries/Geronimo fails with ORA-24798
> (Cannot resume distributed transaction branch on another instance). Don´t be
> fooled by the "on another instance": actually I`m connecting to the same
> Oracle instance (which is not behind a RAC).
> h3. Scenarios
> I tested three scenarios, always using two DataSources within one global XA
> transaction:
> 1. Use two DataSources, each with same user principal
> 2. Use two DataSources, each with same user principal
> 3. Use one DataSource
> In all three scenarios I do the following:
> 1. txManager.begin()
> 2. con1 := Get connection from DataSource1
> 3. SELECT * from DUAL@con1
> 4. con2 := Get connection from DataSource2
> 5. SELECT * from DUAL@con2
> 6. txManager.begin()
> Scenario (two different DataSources) 1 and 2 fail with ORA-24798. Scenario 3
> (one DataSource for both connections) does not fail, but this is only due to
> {{org.apache.aries.transaction.jdbc.internal.XADatasourceEnlistingWrapper}}
> caching connections per (DataSource, Transaction) pair: as a result con1 ==
> con2 in this scenario.
> h3. Problem description
> The root cause is how {{javax.transaction.XAResource#isSameRM(XAResource)}}
> is used in
> {{org.apache.geronimo.transaction.manager.TransactionImpl#enlistResource(XAResource)}}.
> If there is already an {{XAResource}} enlisted in the current transaction
> running on the same RM as the {{XAResource}} to be enlisted (according to
> {{isSameRM}}) then Aries/Geronimo tries to {{TMJOIN}} the branch.
> Now, this is exactly the point where Oracle fails with {{ORA-24798}}.
> Frankie Viet has an excellent discussion about the whole issue at
> http://frankkieviet.blogspot.com/2010/01/how-to-enlist-and-delist-xa-resources.html.
> In summary it says that the sequence
> {noformat}
> 1: // MULTIPLE ACTIVE
> 2: r1.start(xid, TMNOFLAGS);
> 3: r1.isSameRM(r2); // returns true
> 4: r2.start(xid, TMJOIN);
> 5: r2.end(xid, TMSUCCESS);
> 6: r1.end(xid, TMSUCCESS);
> 7: r1.commit(xid, true);
> {noformat}
> is neither working on Oracle nor Websphere MQ (and other commercial systems).
> Instead that link suggests the following sequence working in most cases:
> {noformat}
> 1: // SINGLE ACTIVE 2
> 2: r1.start(xid, TMNOFLAGS);
> 3: r1.isSameRM(r2); // should return true
> 4: ... // use r1
> 5: r1.end(xid, TMSUCCESS);
> 6: r2.start(xid, TMJOIN);
> 7: ... // use r2
> 8: r2.end(xid, TMSUCCESS);
> 9: r1.start(xid, TMJOIN);
> 10: ... // use r1 again
> 11: r1.end(xid, TMSUCESS);
> 12: r1.commit(xid, true);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
