在提交事务之前传递JMS消息

Question

我有一个非常简单的场景，涉及应用程序服务器（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

我和其他人讨论过这个问题，但答案总是如此： “奇怪，它应该开箱即用” 。

我的问题是：

• 它怎么能开箱即用？
• 我的场景听起来很简单，为什么没有更多人遇到类似的麻烦？
• 难道我做错了什么？ 有没有办法正确解决这个问题？

---

以下是关于我对问题的理解的更多细节：

只有在按此顺序处理参与者时才存在此计时问题。 如果2PC以相反的顺序（数据库优先，然后是消息代理）处理参与者应该没问题。 这个问题是随机发生的，但完全可以重现。

我发现无法在Glassfish文档中控制JTA，JCA和JPA规范中分布式事务中参与者的顺序。 我们可以假设它们将在使用它们时按照顺序登记在分布式事务中，但是使用诸如JPA之类的ORM，很难知道何时刷新数据以及何时真正使用数据库连接。 任何的想法？

Answer 1

您正在体验经典的XA 2-PC竞争条件。 它确实发生在生产环境中。

我想到了三件事。

1. 最后一个代理优化，其中JDBC是非XA资源。（失去恢复语义）
2. 有JMS时间交付。 （故意失去实时）
3. 构建重试为JDBC代码。 （对功能的影响最小）

Weblogic有这种LLR优化可以避免这个问题，并为您提供所有XA保证。