aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörn Gersdorf (JIRA) <j...@apache.org>
Subject [jira] [Created] (ARIES-1265) Aries Transactions: Transaction Enlisting failing for multiple OracleXADataSources/Connections
Date Tue, 14 Oct 2014 06:50:33 GMT
Jörn Gersdorf created ARIES-1265:
------------------------------------

             Summary: 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


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

Mime
View raw message