我有一个非常简单的场景,涉及应用程序服务器(Glassfish)中的数据库和 JMS 。这个场景很简单:
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
我已经讨论了这个问题with others,但答案总是如此:“奇怪,它应该开箱即用”。
我的问题是:
以下是关于我对问题的理解的更多细节:
此时间问题仅在参与者按此顺序处理时才存在。如果2PC以相反的顺序(数据库优先,然后是消息代理)处理参与者应该没问题。问题是随机发生的,但完全可以重现。
我发现无法在Glassfish文档中控制JTA,JCA和JPA规范中分布式事务中参与者的顺序。我们可以假设它们将在使用它们时按照顺序登记在分布式事务中,但是使用诸如JPA之类的ORM,很难知道何时刷新数据以及何时真正使用数据库连接。有什么想法吗?
答案 0 :(得分:11)
您正在体验经典的XA 2-PC竞争条件。它确实发生在生产环境中。
我想到了三件事。
Weblogic有这种LLR优化可以避免这个问题,并为您提供所有XA保证。