Multi resource XA transactions sometimes act incorrectly [SPR-12535]

[spring-projects-issues]

Trevor Stevens opened SPR-12535 and commented

When using XA Transactions sometimes messages are delivered to the queue before they are committed to the database. We have attempted the following within both TomEE and Wildfly and have been able to reproduce this issue in both. I'm attaching a sample project which should allow others to reproduce this as well.

Expected operation, each step represents a seperate XA transaction.

1. @Service send JMSMessage using JMSTemplate
2. Listener1 within a DefaultMessageListenerContainer uses JPA to persists entity and sends a JMSMessage containing ID of entity using JMSTemplate
3. Listener2 within a DefaultMessageListenerContainer attempts to retrieve entity by ID from JPA

My thought was that within an XA transaction both the JPA persist and the JMS send must complete before the transaction can commit successfully. We have been trying to tackle a strange case where after the listener for #2 completes the message from #2 is then delivered to #3 but the ID is not present in the database yet and the entity cannot be retreived.

I'm attaching a snippent from a log showing both a passing and failing case of the above steps. Since we have been unable to find any fault with our configuration and due the intermittent nature of this we can only assume that a bug exists somewhere within Springs handling of XA transactions.

---

Affects: 3.2.12

Reference URL: https://github.com/jej2003/simple-spring

Attachments:

• XA-failure.txt (6.26 kB)

[spring-projects-issues]

Stéphane Nicoll commented

Unfortunately, Spring has nothing to do with this problem.

Your XA transaction has basically two XA resources, one for the database and one for your JMS session. During 2PC, the transaction manager calls prepare on both, gets the replies and then calls commit on both again. At that point, each XA resources are free to do things any way they want (including actually committing in parallel). Nothing in the current JTA spec defines the order in which XA resources are processed.

What you experienced is perfectly reproductible without Spring.

There are a few things you may consider to alleviate that problem though, the easiest being to retry a JMS message that tries to lookup something that is not there while it should (because you're passing the ID or something). Better, make sure to denormalize the data a bit so that you can still process the message even if the entity is "not there yet" (but that really depends on your use case).

Additional references:

• http://stackoverflow.com/questions/14595118/xa-jta-transaction-jms-message-arrives-before-db-changes-are-visible
• https://parleys.com/play/514892250364bc17fc56b9fc