用于JMS和DB操作的XA或非XA

我对XA和非XA世界相当陌生。我的要求是从队列中读取消息，直到没有消息为止。对于队列中的每条消息，转到DB并执行一些事务，如select、insert、update

这是否可以使用非XA数据源实现？我目前正在使用XA数据源，但了解到它成本高昂且性能受到影响

---

谢谢你的帮助！谢谢

如果您需要在事务中包括与JMS连接的交互（即发送或接收消息）以及使用db连接连接数据库，那么您肯定需要XA数据源，因为您的事务是

在两阶段提交事务中，您要么将更改提交到所有资源（在您的示例中是JMS和DB资源），要么在任何一个资源出现问题时回滚所有更改

为此，您需要连接到启用XA的数据源。

---

此外，在Java EE容器中，JMS连接应该已经启用XA

XA保证一条消息匹配1个且仅匹配1个DB事务。 让我们想想没有XA会发生什么（只是许多可能情况中的一种）：

MDB选择一条消息

MDB执行一个DB任务（假设一切顺利……没有例外）

应用程序服务器jdk由于某种原因崩溃，或者MDB线程仍在运行时出现网络故障

为简单起见，我们考虑服务器重新启动：因为MDB没有提交事务，因此消息仍然在队列中。

另一个MDB获取消息并重复DB事务

幸运的是，XA存在！：-） 从性能的角度来看，要付出代价，但（服务的）质量总是有代价的

考虑一下。基本上：

• 步骤1：提交DB事务
• 步骤2：提交JMS事务

可能的错误场景：

数据库事务失败

DB事务成功JMS事务失败

都成功了

不是1，也不是3会使系统处于不一致的状态。在1的情况下，您只需要重新发送消息

来处理场景2。您需要在系统中引入重复检查。因此，本质上，您的事务管理与此类似：

//pseudo code
if (isDublicate(message))
   commitJMSTransaction();
else
   doYourBusinessLogic();
   doYourDBOperation();
   commitDBTransaction();
   commitJMSTransaction();

---

如果JMS事务失败，您的message broker将重试发送消息（或者您需要根据代理设置手动重新发送消息），但您的重复检查将检测到该消息并将其从队列中删除。

为了让您了解XA和非XA事务，我简要解释一下， XA事务是“全局事务”。 非XA事务是“本地事务”

XA事务涉及一个协调事务管理器，其中一个或多个数据库（或其他资源，如JMS）都涉及单个全局事务。如果它连接到多个数据库，那么它就是XA

---

非XA事务没有事务协调器，单个资源自己完成所有事务工作。这将只有一个数据库作为资源。

您在这里做了几个假设，这些假设不一定正确：数据库和排队系统都必须支持XA协议。这些假设是有问题的。他说他可以在XA数据源和非XA数据源之间进行选择，但他担心性能。WebSphere消息传递确实支持XA，这是J2EE规范的要求。我只是展示了一个XA如何帮助的示例。您可能应该解释如何管理队列，使用什么产品。一些数据库供应商还提供排队解决方案，这将使您的生活更轻松。