用于 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
Websphere MQ 作为 txn 协调器:- 由于 db2 无法启动 xa,MQ.begin() 在 mq 退出后失败