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

【问题标题】：XA or non-XA for JMS and DB operation用于 JMS 和 DB 操作的 XA 或非 XA
【发布时间】：2014-02-06 14:09:45
【问题描述】：

我对 XA 和非 XA 世界还很陌生。我的要求是从队列中读取消息，直到没有消息。对于队列中的每条消息，转到 DB 并执行一些事务，例如选择、插入、更新。

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

感谢任何帮助！谢谢

【问题讨论】：

您应该解释一下队列是如何管理的，使用什么产品。一些数据库供应商还提供排队解决方案，这将使您的生活更轻松。

【解决方案1】：

如果您需要在事务中包含与 JMS 连接 的交互（即发送或接收消息）以及与数据库的连接，请使用 db 连接那么您肯定需要一个 XA 数据源，因为您的事务是 two-phase commit (2PC) transaction。

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

为此，您需要连接到支持 XA 的数据源。此外，在 Java EE 容器中，JMS 连接应该已经启用 XA。

【讨论】：

【解决方案2】：

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

MDB 选择一条消息
MDB 执行数据库作业（假设一切顺利...没有例外）
应用服务器 jdk 因某种原因崩溃或 MDB 线程仍在运行时出现网络故障
为简单起见，让我们考虑重新启动服务器：由于 MDB 未提交事务，因此消息仍在队列中。
另一个 MDB 获取消息并重复 DB 事务。

幸运的是，XA 存在！ :-) 从性能的角度来看，是有成本的，但质量（服务）总是有成本的！

【讨论】：

这里做了几个假设，不一定正确：数据库和排队系统都必须支持XA协议。
这些假设是有问题的。他说他可以在 XA 数据源和非 XA 数据源之间进行选择，但他担心性能。 WebSphere Messaging 确实支持 XA，这是 J2EE 规范的要求。我仅展示了 XA 如何提供帮助的示例。

【解决方案3】：

考虑1.5 phase commit。基本上：

第 1 步：提交数据库事务
第 2 步：提交 JMS 事务。

可能的错误场景：

数据库事务失败。
DB 事务成功 JMS 事务失败。
一切顺利。

不是 1，也不是 3 会使您的系统处于不一致状态。如果是1，则只需要重新发送消息即可。

要处理场景 2。您需要在系统中引入重复检查。所以基本上你的事务管理看起来像这样：

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

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

【讨论】：

【解决方案4】：

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

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

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

【讨论】：