rollback not called in enlisted XA resource

[neilcurzon]

We have a situation in a 4 node JBoss-4.0.3SP1/JBoss Transactions 4.2.2 in which

A1 invokes a method on B1 which enlists a MySql XA connection in the transaction and does some work successfully.

A1 invokes a method on A2 which then invokes a method on B2 which also enlists a MySql XA connection. Some work fails, which results in an exception being caught. The transaction is set rollback only in B2.

We see the following sequence of calls on B1's XA resource: start, end, prepare, rollback (expected). On B2's XA resource we see only start. (we expect start, end, prepare, rollback).

Currently, we're working on a simplified test case to post. In the mean time, does anybody have any info that might help us?

Thanks in advance.

[marklittle]

What is the relationship between the A's, B's and JBossAS instances?

[jhalliday]

Are you sure 2 distinct resources are being enlisted? I would expect this behaviour if the second call to MySQL was simply reusing the previously enlisted resource.

[neilcurzon]

What is the relationship between the A's, B's and JBossAS instances?

Each of A1, A2, B1 and B2 are running on a separate instance of JBoss on separate machines. The EJBs being called are annotated @ejb.transaction type="Required" @ejb.transaction-type type="Container"

"jhalliday" wrote:
Are you sure 2 distinct resources are being enlisted? I would expect this behaviour if the second call to MySQL was simply reusing the previously enlisted resource.

Yes, they are definitely separate resources. They're calling different databases on different machines.

[weston.price]

Also, could you post your *-ds.xml file for both resources as well as the MySQL driver/DB version you are using.

[neilcurzon]

Also, could you post your *-ds.xml file for both resources as well as the MySQL driver/DB version you are using.

We're running MySQL 5.0.32 on linux on all four machines. We're using mysql-connector-java 5.0.5, but we're pretty sure that's not the issue -- when we enlist the resource we wrap it in a class that outputs the name of the method called before passing on the call to the MySQL resource. We don't see anything except start being called.

Here are the mysql-xa-ds.xml files:

B1

<datasources>
 <xa-datasource>
 <jndi-name>B1/DS1</jndi-name>
 <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
 <xa-datasource-property name="URL">jdbc:mysql://localhost:3306/testdb?autoReconnect=true</xa-datasource-property>
 <user-name>username</user-name>
 <password>pw</password>
 <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
 <max-pool-size>30</max-pool-size>
 <min-pool-size>10</min-pool-size>
 <blocking-timeout-millis>2000</blocking-timeout-millis>
 <idle-timeout-minutes>2</idle-timeout-minutes>
 <track-connection-by-tx>true</track-connection-by-tx>
 <no-tx-separate-pools>true</no-tx-separate-pools>

 <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
 <metadata>
 <type-mapping>mySQL</type-mapping>
 </metadata>
 </xa-datasource>
</datasources>

B2's mysql-xa-ds.xml is the same except for the JNDI name.

[marklittle]

"neilcurzon" wrote:
We see the following sequence of calls on B1's XA resource: start, end, prepare, rollback (expected).

Again to clarify: the error you mentioned happens during/after prepare?

[neilcurzon]

Again to clarify: the error you mentioned happens during/after prepare?

The error is that we never see anything beyond start on B2. We check the global transaction ID passed into start in B2, and it matches the ID of the transaction that we see rollback on B1.

[weston.price]

Just as a test, can you try adding the following to your *-ds.xml file:

<isSameRM-override-value>false</isSameRM-override-value>

[weston.price]

Note, this should be done for both resources.

[marklittle]

You misunderstood me. I was asking about where the "error" occurs that subsequently causes the transaction to roll back. You say "some work fails" and I'd like to know what that is and how it fails. The reason is that you say:

We see the following sequence of calls on B1's XA resource: start, end, prepare, rollback (expected).

so if you see prepare then rollback on the XAResource that means the transaction was trying to commit (at least on the first resource) and caught an error during prepare that then causes it to rollback.

[neilcurzon]

You misunderstood me.....

The error happens before prepare, and results in an exception being caught within B2, and the transaction being set to rollback only in the session context on B2.

[neilcurzon]

Note, this should be done for both resources.

We repeated the test with the modified ds.xml and got the same result.

[marklittle]

"neilcurzon" wrote:
A1 invokes a method on B1 which enlists a MySql XA connection in the transaction and does some work successfully.

A1 invokes a method on A2 which then invokes a method on B2 which also enlists a MySql XA connection. Some work fails, which results in an exception being caught. The transaction is set rollback only in B2.

We see the following sequence of calls on B1's XA resource: start, end, prepare, rollback (expected). On B2's XA resource we see only start. (we expect start, end, prepare, rollback).

This is where a whiteboard would have been nice ;-) From what I can see, A1 (or maybe B1) controls the transaction that flows to A2/B2. (So you're using the JTS component of JBossTS). As you say, although the transaction is set to rollback-only in B2, the transaction contoller attempts to commit the transaction in A1/B1. This means that you do get to the prepare stage for the B1 XAResource and at that point the coordinator invokes prepare on the XAResource at B2. Like you, I'd expect to see a rollback on the XAResource at that point. Can you turn on debugging for JBossTS, then we can see the flow of messages and method invocations?

[weston.price]

And trace at the JBossJCA layer as well. There is already an entry in your log4j.xml file to do this, simly uncomment it.