XA/JTA transaction: JMS message arrives before DB changes are visible

Question

Context is:

• producer (JTA transaction PT) is both sending message to JMS queue and making DB update;
• consumer (JTA transaction CT) listens on same queue and reads DB when message is received;
• application server - WebLogic, DB - Oracle.

I've observed, that sometimes CT is not (yet?) able to see DB changes of PT, event if corresponding JMS message is already received (PT is committed?).

It seems that JTA can't guarantee consistency of such kind (this was also confirmed in Jurgen Holler's presentation "Transaction Choices for Performance").

What is the best way to avoid such problem (except obvious - not using JTA)?

Thanks.

Answer 1

some options are outlined here: http://jbossts.blogspot.co.uk/2011/04/messagingdatabase-race-conditions.html

Answer 2

So it seems there is no simple, elegant and fail-proof solution for that. In our case it was decided to rely on simple redelivery mechanism (throwing exception and letting JMS message to be redelivered after certain amount of time).

Also considered:

• Marking DB datasource as and expecting Last Resource Commit Optimization (LRCO) to kick-in (thus partially controlling order of commits inside XA transaction). Rejected due to dependency to internals of application server (WL).

• Setting DeliveryDelay to JMS message, so it can be consumed only after some time, when (supposedly) DB sync is over. Rejected due to lack of guarantee and need to fine-tune it for different environments.

Blog post mentioned in other answer indeed contains all these and several other options covered (but no definitive one).