Entrega de mensaje JMS antes de que se confirme la transacción

Question

Tengo un escenario muy sencillo que implica un base de datos y JMS 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 el mensaje se entrega antes de la inserción se ha cometido en la base de datos. Esto es realmente comprensible si tenemos en cuenta la fase 2 protocolo de confirmación:

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 problema con otros , pero la respuesta siempre fue:. "Strange, debería funcionar fuera de la caja"

Mis preguntas son entonces:

• Como no podía trabajar fuera de la caja?
• Mi escenario suena bastante simple, ¿por qué no hay más gente con problemas similares?
• ¿Estoy haciendo algo mal? ¿Hay una manera de solucionar este problema correctamente?

---

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

Este problema de temporización existe sólo si el participante se tratan en este orden. Si el 2PC trata a los participantes en el orden inverso (base de datos primero y luego intermediario de mensajes) que debe estar bien. El problema estaba sucediendo al azar, pero completamente reproducible.

he encontrado ninguna manera de controlar el orden de los participantes en las transacciones distribuidas en las especificaciones JTA, JCA y la APP ni en la documentación de GlassFish. Podríamos suponer que se alistaron en la transacción distribuida de acuerdo a la orden cuando se utilizan, pero con un ORM como APP, es difícil saber cuando los datos se vacían y cuando la conexión de base de datos se utilizan realmente. Alguna idea?

Answer 1

Usted está experimentando el clásico XA condición de carrera 2-PC. Lo que ocurre en entornos de producción.

Hay 3 cosas que vienen a la mente.

optimización
1. Última agente cuando JDBC es el recurso que no sea XA. (Pierde la semántica de recuperación)
2. Haga que JMS Time-To-Deliver. (Deliberadamente perder tiempo real)
3. Construir reintentos en código JDBC. (Menor efecto en la funcionalidad)

Weblogic tiene esta optimización LLR evita este problema y le da todas las garantías XA.