[jira] [Commented] (ARIES-1265) Aries Transactions: Transaction Enlisting failing for multiple OracleXADataSources/Connections

["Benjamin Graf (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARIES-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14322972#comment-14322972 ] 

Benjamin Graf commented on ARIES-1265:
--------------------------------------

By the way it worth thinking about adding a isSameRM override flag at all (true/false).

> 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)