Доставка сообщения JMS до совершения транзакции

Question

У меня очень простой сценарий с участием база данных и JMS В сервере приложений (Glassfish). Сценарий мертвый простой:

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. 

Проблема в том, что иногда Сообщение доставляется до того, как вставка будет совершена в базе данных. Это на самом деле понятно, если мы рассмотрим 2 -фазовый протокол коммита:

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

Я обсудил эту проблему с другими, но ответ всегда был: "Странно, это должно работать из коробки".

Мои вопросы тогда:

• Как это могло работать из коробки?
• Мой сценарий звучит довольно просто, почему нет больше людей с подобными проблемами?
• Я делаю что-то неправильно? Есть ли способ правильно решить эту проблему?

---

Вот немного более подробной информации о моем понимании проблемы:

Эта проблема времени существует только в том случае, если участники обрабатываются в этом порядке. Если 2PC обрабатывает участников в обратном порядке (сначала база данных, то это брокер сообщений), это должно быть в порядке. Проблема произошла случайно, но полностью воспроизводима.

Я не нашел никакого способа контролировать порядок участников в распределенных транзакциях в спецификациях JTA, JCA и JPA, ни в документации Glassfish. Мы могли бы предположить, что они будут зачислены в распределенную транзакцию в соответствии с порядком, когда они будут использоваться, но с помощью ORM, такого как JPA, трудно понять, когда данные промываются и когда подключение к базе данных действительно используется. Есть идеи?

Answer 1

Вы испытываете классическое состояние гонки XA 2-PC. Это происходит в производственных средах.

У меня приходят 3 вещи.

1. Оптимизация последнего агента, где JDBC является ресурсом без XA. (Потеряйте семантику восстановления)
2. Иметь JMS Time-For. (Намеренно терять в реальном времени)
3. Build Retres в код JDBC. (Наименьшее влияние на функциональность)

Weblogic имеет эту оптимизация LLR, избегает этой проблемы и дает вам все гарантии XA.