Atomikos Forum

We have the following scenario:

XA Jms resource (Tibco)
Non XA JDBC datasource (Sql Server)

We have to use a non-xa jdbc datasource because 1) we can't get the Opta XA datasource to work with Atomikos and 2) we can't use the MS XA datasource because of an issue with the way they try to handle clustered failover.

In any event, we are seeing the following and I'm wondering if it is because of the presence of a non-xa resource in our transactions.

The following happens inside a transaction:

-record is inserted into the database
-jms message sent to a queue with PK from record above

When the message is received by the JMS listener from the queue above and it tries to retrieve the record by the PK, occasionally, the record is not found. This can only occur if the jms message is committed before the database update is, which should not happen in a proper transaction.

Can this happen using Atomikos' version of the last resource gambit with our non-xa datasource?

This could happen in some scenarios. Non-xa is not safe for multiple systems (such as JDBC+JMS). But it shouldn't be every other transaction, only (at most) after crash/restart...

It's not happening after every transaction but in a 10k transactions test, it happened about 0.5% of the time, not during startup or shutdown.

Hi,

This is a common XA pitfall: the transaction manager does not guarantee the commit order, only that each resource will either commit or rollback.

In practice, you can never rely on the order the resources are going to be committed. Maybe the JMS message will be sent first, maybe the database insert will happen first.

Right, but in the last resource gambit (or any reasonable facsimile) the non XA participant HAS to be committed last.

Typically, the txmanager would call prepare() on all the xa participants FIRST and then call commit() on the non xa participant during the prepare phase. If the non xa participant throws an exception during the commit, the txmanager rolls back all the other participants, otherwise it invokes commit() on all of them.

In order to implement the LRG, you HAVE to order the participants.

Hi,

Thanks for the feedback.

Actually, our non-xa support was originally intended for 1 datasource, not 2 or more (in which case LRC is unsafe - even as you describe it, BTW).

We could go about tuning it in a future release if there is a compelling use case (of if you want to sponsor ;-)

Cheers
Guy