22

我有一个非常简单的场景，涉及应用程序服务器（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 时，很难知道何时刷新数据以及何时真正使用数据库连接。任何的想法？

4

1 回答 1

12

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

我想到了 3 件事。

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

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

于 2010-03-29T11:32:55.947 回答