Tengo un escenario muy simple que involucra unbase de datos y unJMS en un servidor de aplicaciones (Glassfish). El escenario es muy simple:

1. an EJB inserts a row in the database and sends a message.
2. when the message is delivered with an MDB, the row is read and updated. 

El problema es que a veces elel mensaje se entrega antes de que se haya confirmado la inserción en la base de datos Esto es realmente comprensible si consideramos el protocolo de confirmación de 2 fases:

1. prepare JMS
2. prepare database
3. commit JMS
4. ( tiny little gap where message can be delivered before insert has been committed)
5. commit database

He discutido este problemacon otros, pero la respuesta siempre fue:"Extraño, debería salir de la caja".

Mis preguntas son entonces:

¿Cómo podría funcionar fuera de la caja?Mi escenario parece bastante simple, ¿por qué no hay más personas con problemas similares?¿Estoy haciendo algo mal? ¿Hay alguna manera de resolver este problema correctamente?

Aquí hay un poco más de detalles sobre mi comprensión del problema:

Este problema de tiempo solo existe si el participante es tratado en este orden. Si el 2PC trata a los participantes en el orden inverso (primero la base de datos y luego el intermediario de mensajes), eso debería estar bien. El problema estaba sucediendo al azar pero completamente reproducible.

No encontré ninguna forma de controlar el orden de los participantes en las transacciones distribuidas en las especificaciones JTA, JCA y JPA ni en la documentación de Glassfish. Podríamos suponer que se incluirán en la transacción distribuida de acuerdo con el orden cuando se usen, pero con un ORM como JPA, es difícil saber cuándo se vacían los datos y cuándo se usa realmente la conexión de la base de datos. ¿Alguna idea?