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

Posted

技术标签:

【中文标题】用于 JMS 和 DB 操作的 XA 或非 XA【英文标题】:XA or non-XA for JMS and DB operation 【发布时间】: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 事务没有事务协调器,单个资源自己完成所有事务工作。这将只有一个数据库作为资源。

【讨论】:

以上是关于用于 JMS 和 DB 操作的 XA 或非 XA的主要内容,如果未能解决你的问题,请参考以下文章

执行 XA 事务时 DB2 死锁问题 SQLCODE=-911, SQLERRMC=68

从 z/OS 批处理作业运行 XA/JTA 事务

在 JBoss 上为 DB2 创建 XA 数据源

分布式事物之 xa协议两阶段提交

ABB 800XA学习笔记47:工程组态界面6

Websphere MQ 作为 txn 协调器:- 由于 db2 无法启动 xa,MQ.begin() 在 mq 退出后失败