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