Thanks for your feedback.
The EJB that updates the database and sends the message is running within a distributed transaction. From the bean point of view the transactional semantics is ok: the database update and the message sending are committed or rolled back together when the transaction completes. No message is ever delivered if transaction is rolled back.
We first update the database then send the JMS message. We are using JPA to load and update the entity in database, so it's hard to say when the database changes are actually flushed, and if it impacts the order of events in the 2 phase commit protocol.
At a point in time, there are two participants enlisted in the transaction manager (the database connection and the JMS queue, both XAResource). I don't know how the transaction manager decides the order of the prepare/commit sequence. The transaction manager doesn't know the nature of the participants and doesn't know what operations were performed on each participant. From my understanding the order shouldn't matter and it could be either database-JMS or JMS-database.
Unfortunately, if it turns out that the transaction manager commits first the JMS then the database, the message [i]may[/i] be delivered before the database changes are done.
The problem is reproducible, but not systematic. This could be explained either because of the delivery delay, or because the order in the 2 phase commit is not deterministic.
[Message sent by forum member 'ewernli' (ewernli)]
http://forums.java.net/jive/thread.jspa?messageID=352031