JMS -> Processing -> MessageStore -> JMS JTA Transaction Commit Order

[nickspacek]

Hi folks,

Having some trouble getting things to commit properly, and maybe I'm going about it wrong but it seems pretty close.

What I'm aiming for is that unless the application reads the message, processes, and then sends the new message out again successfully the transaction should fail. Seems pretty straightforward.

What I have is a message-driven-channel-adapter listening for (claim-check) messages. When it receives one, it: checks out the payload from a MySQL DB, does some processing, check the payload into a MySQL DB, and sends this claim check out via JMS.

Right now it mostly works, except that when the transaction is committed it commits the JMS first. It may be doing this to commit the read (and removal) of the initial message, but what happens is the JMS message is picked up by the other app listening to this queue before the payload is saved in MySQL (because that part of the transaction hasn't been committed).

I am using Atomikos to manage this JTA transaction.

[Gary Russell]

As you have found, XA is not a panacea.

Although you get ACID properties (albeit with much overhead) the resources are still (eventually) committed separately, causing the issue you are seeing.

You might want to consider using Spring Transaction Synchronization instead, where the JDBC transaction will be committed first, immediately followed by the JMS transaction. There is, however, a small possibility of a failure between the two commits, which means you might have to code for the possibility of duplicate messages.

See Best Effort 1PC in http://www.javaworld.com/javaworld/j...nsactions.html.

[nickspacek]

Rats. I did discover that when I have a DB poller initiating the transaction, the JDBC changes are committed first and then JMS.

I ended up going with the ChainedTransactionManager, hopefully something similar will make it into Spring official in the future (I've voted and watched the relevant JIRA issue).