У меня есть очень простой сценарий с участиембаза данных и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. 

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

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, трудно определить, когда данные сбрасываются и когда соединение с базой данных действительно используется. Любая идея?