在事务提交之前传递JMS消息 [英] Delivery of JMS message before the transaction is committed

问题描述

我有一个非常简单的场景，涉及应用程序服务器（Glassfish）中的数据库和 JMS 。方案很简单：

  1。 EJB在数据库中插入一行并发送消息。 
 2.当使用MDB传递消息时，将读取和更新行。问题是有时候       >在数据库中。如果我们考虑2阶段提交协议，这实际上是可以理解的：
  1。准备JMS 
 2.准备数据库
 3. commit JMS 
 4.（微小的差距，在插入提交之前可以传递消息）
 5.提交数据库
  
我已经讨论过这个问题与其他人，但答案总是：奇怪，它应该开箱即用。
 
 
 
我的问题是：
 
 
 
 
 
如何开箱即用？ 
 
 
我的情况听起来很简单，为什么没有更多有类似烦恼的人？
 
 
我做错了什么？是否有正确解决此问题的方法？
 
 
 
 
 
 
 
 
关于我对问题的理解：
 
 
 
此时间问题仅在参与者按此顺序处理时才存在。如果2PC以相反的顺序处理参与者（数据库第一，然后消息代理），应该是罚款。 
 
 
 
我没有办法控制JTA，JCA和JPA规范中的分布式事务中的参与者的顺序， Glassfish文档。我们可以假设他们将在分布式事务中根据使用它们的顺序登记，但是使用ORM（例如JPA），很难知道何时刷新数据以及何时真正使用数据库连接。任何想法？
解决方案
您遇到了经典的XA 2-PC竞争条件。 
 
 
 
我有三种想法。
 
 
最后一个代理优化，其中JDBC是非XA资源。（丢失恢复语义）
 
 
具有JMS时间交付功能。 （故意丢失实时）
 
 
构建对JDBC代码的重试。 （对功能的最小影响）
 
 
 Weblogic有这个LLR优化避免这个问题，并给你所有的XA保证。
 
I have a very simple scenario involving a database and a JMS in an application server (Glassfish). The scenario is dead simple: 
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. 
The problem is that sometimes the message is delivered before the insert has been committed in the database. This is actually understandable if we consider the 2 phase commit protocol:
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
I've discussed this problem with others, but the answer was always: "Strange, it should work out of the box".

My questions are then:


How could it work out-of-the box? 
My scenario sounds fairly simple, why isn't there more people with similar troubles?
Am I doing something wrong? Is there a way to solve this issue correctly?




Here are a bit more details about my understanding of the problem:

This timing issue exist only if the participant are treated in this order. If the 2PC treats the participants in the reverse order (database first then message broker) that should be fine. The problem was randomly happening but completely reproducible.

I found no way to control the order of the participants in the distributed transactions in the JTA, JCA and JPA specifications neither in the Glassfish documentation. We could assume they will be enlisted in the distributed transaction according to the order when they are used, but with an ORM such as JPA, it's difficult to know when the data are flushed and when the database connection is really used. Any idea?
解决方案
You are experiencing the classic XA 2-PC race condition. It does happen in production environments.

There are 3 things coming to my mind.

Last agent optimization where JDBC is the non-XA resource.(Lose recovery semantics)
Have JMS Time-To-Deliver. (Deliberately Lose real time)
Build retries into JDBC code. (Least effect on functionality)
Weblogic has this LLR optimization avoids this problem and gives you all XA guarantees.

                        
这篇关于在事务提交之前传递JMS消息的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！