Can it be a database bug that the data is not locked on flush in
beforeCompletion? What are you using for JPA?
You can also try to use a non-XA resource for JPA (if there is only 1 database
involved) - this is supported as "last-agent-optimization". In which case the
database commit will happen before JMS.
Regards,
-marina
glassfish_at_javadesktop.org wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>