XAER_NOTA Problems

[oravecz]

I am seeing the invalid xid problem when I run multiple clients simultaneously against my server. It is very difficult to debug what is causing this problem, but I have the following hypothesis.

Most of my XA transactions end up crossing many EJB methods. Each of these methods will pull a connection from the pool (it is properly enlisted in the XA transaction), use the connection, and return it to the pool. After many methods execute, the XA transaction is committed. This works fine as long as I only run one client.

With two clients, each client starts its own XA transaction. Each set of method gets connections from the pool and returns them to the pool. Is there any code in place that prevents a connection that has been enlisted in a particular XA transaction from being doled out to another XA transaction? I feel that my error occurs when a connection attempts to register with another XID before the first XA transaction commits.

Do/Can the connections in the pool have any concept of which XID they are associated with and the fact that the XID may not have been committed yet? If so, I may be able to add the necessary code to restrict these objects to their own XIDs.

Is there a listener interface for the TM that the pool can register with to learn about XA commits?

[davidjencks]

The whole point of xa rather than 2pc IMO is that a connection can be used in many transactions sequentially without the transaction being committed. A typical use of a connection/xaresource would be

get connection from pool (app)
enlist in current tx/xid (jboss)
do some work (app)
close handle (app)
delist from current tx/xid (jboss)
put back in pool (jboss).

At this point the connection should be available for use by another thread/tx/xid even though the first tx has not completed.

What jboss/db are you using?

[oravecz]

> The whole point of xa rather than 2pc IMO is that a
> connection can be used in many transactions
> sequentially without the transaction being committed.

The Sybase XA engineers stated that this is not possible. The transaction must be committed before the connection can be released to _another_ transaction.

Looking more closely at the jBoss code, it looks like the XA connections listen to transaction events, and are supposed to be released to the pool when the transaction completes or fails. i am in the process of debugging this code now.

> A typical use of a connection/xaresource would be
>
> What jboss/db are you using?

jBoss 2.6/Sybase 12.5 - Can't go to jBoss 3.0 until the associateConnection is working for XA.