XA 事务处理

本文选自迷你书《Java 事务设计策略》的第五章，译者翟静。

为了说明 X/Open XA 接口在 JTA 事务管理中的重要性，以及它使用的时机，我们以前一章提到的一段固定收入交易的 EJB 代码为例：

 
@TransactionAttribute(TransactionAttributeType.REQUIRED) 
 
public void placeFixedIncomeTrade(TradeData trade) throws Exception { 
    try { 
        ... 
        Placement placement =  placementService.placeTrade(trade);
        executionService.executeTrade(placement); 
    } catch (TradeExecutionException e) { 
        log.fatal(e); 
        sessionCtx.setRollbackOnly(); 
        throw e; 
    } 
}         

这段代码中，首先预置了一笔交易，而后执行交易，这两个操作更改了数据库中不同的表。正如我们在前面章节看到的，如果在标准的非 XA 环境，这段代码保证遵循 ACID 准则。假设我们收到了一个新的需求，该公司要求在每一笔固定收入交易时都向其他系统发送一条 JMS 消息，以关注交易活动。为简单起见，我们同样假设在 sendPlacementMessage() 方法中实现所有的 JMS 消息逻辑。上面的例子被修改如下以实现新功能：

 
@TransactionAttribute(TransactionAttributeType.REQUIRED)
 
public void placeFixedIncomeTrade(TradeData trade) throws Exception { 
   try { 
       ... 
       Placement placement =  placementService.placeTrade(trade); 
       placementService.sendPlacementMessage(placement); 
       executionService.executeTrade(placement); 
   } catch (TradeExecutionException e) { 
       log.fatal(e); 
       sessionCtx.setRollbackOnly(); 
       throw e;
   } 
} 

虽然以上的修改足够简单，这段代码却不会保证 ACID 准则。如果 executeTrade() 方法抛出了 TradeExecutionException，数据库更改将会回滚，但交易预置的消息将会被发送到 JMS 的 queue 或 topic。事实上，交易预置消息很可能在 sendPlacementMessage() 方法执行完成后就被 queue 或 topic 释放（消费）掉了。

因为在非 XA 环境中，消息队列的插入过程独立于数据库更新操作，ACID 准则中的原子性和独立性不能得到保证，从而整体上数据完整性受到损害。我们需要的是，有一种方式能够让消息队列和数据库处于单一事务的控制之下，以至于两个资源能被协调形成单一工作单元。使用 X/Open 的 XA 接口，我们便能够做到协调多个资源，保证维持 ACID 准则。

XA 接口详解

X/Open XA 接口是双向的系统接口，在事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。事务管理器控制着 JTA 事务，管理事务生命周期，并协调资源。在 JTA 中，事务管理器抽象为 javax.transaction.TransactionManager 接口，并通过底层事务服务（即 JTS）实现。资源管理器负责控制和管理实际资源（如数据库或 JMS 队列）。下图说明了事务管理器、资源管理器，以及典型 JTA 环境中客户端应用之间的关系：

注意，上图中 XA 接口形成了事务管理器和资源管理器之间的通信桥梁。因为 XA 接口的双向特质，XA 支持两阶段提交协议，我们将在本章的后续部分讨论。

本章所叙述的内容很难覆盖 XA 接口的所有细节。如果读者关心 XA 的细节，请参考 X/Open XA 接口规范（可在 http://www.opengroup.org/onlinepubs/009680699/toc.pdf 通过 pdf 的格式拿到）。

什么时候应该使用 XA？

在 Java 事务管理中，常常令人困惑的一个问题是什么时候应该使用 XA，什么时候不应使用 XA。由于大多数商业应用服务器执行单阶段提交（one-phase commit）操作，性能下降并非一个值得考虑的问题。然而，非必要性的在您的应用中引入 XA 数据库驱动，会导致不可预料的后果与错误，特别是在使用本地事务模型（Local Transaction Model）时。因此，一般来说在您不需要 XA 的时候，应该尽量避免使用它。下面的最佳实践描述了什么时候应当使用 XA：

最佳实践

仅在同一个事务上下文中需要协调多种资源（即数据库，以及消息主题或队列）时，才有必要使用 X/Open XA 接口。

这里体现了一个重要的观点，即虽然您的应用可能使用到多个资源，但仅当这些资源必须在同一个事务范畴内被协调时，才有必要用到 XA。多个资源的情形包括访问两个或更多的数据库（并不止是多个表，而是彼此分开的多个数据库），或者一个数据库加上一个消息队列，又或者是多个消息队列。您可能有一个应用同时使用到一个数据库和一个消息队列。然而，如果这些资源并不在同一个事务中使用，就没有必要去用 XA。本章开始的代码，预置一个固定收入交易，而后向队列发送一条消息，就是需要使用 XA 以便维护 ACID 特性的例子。

需要并使用 XA 最常见的场景是在同一个事务中协调数据库更改和消息队列（或主题）。注意这两种操作有可能在应用完全不同的地方出现（特别是在使用像 hibernate 这样的 ORM 框架的时候）。XA 事务必须在回滚事件发生时协调两种类型的资源，或让更改与其他事务保持隔离。如果没有 XA，送往队列或主题的消息甚至会在事务终止前到达并被读取。而在 XA 环境下，队列中的消息在事务提交之前不会被释放。此外，如果是协调一个操作型数据库和一个只读数据库（即参考数据库），您就不需要 XA。然而，由于 XA 支持“只读优化”，当把一个只读数据源引入 XA 事务时，您可能并不会看到任何的性能损失。

当意图在您的企业 Java 应用中使用 XA 时，有几个隐含的问题是需要考虑的。这些问题包括两阶段提交（2PC，two-phase commit process），经验异常，以及 XA 驱动的使用。以下章节分别详述了这些问题。

两阶段提交

两阶段提交协议（The two-phase commit protocol，2PC）是 XA 用于在全局事务中协调多个资源的机制。两阶段协议遵循 OSI（Open System Interconnection，开放系统互联）/DTP 标准，虽然它比标准本身早若干年出现。两阶段提交协议包含了两个阶段：第一阶段（也称准备阶段）和第二阶段（也称提交阶段）。一个描述两阶段提交很好的类比是典型的结婚仪式，每个参与者（结婚典礼中的新郎和新娘）都必须服从安排，在正式步入婚姻生活之前说“我愿意”。考虑有的杯具情形，“参与者”之一在做出承诺前的最后一刻反悔。两阶段提交之于此的结果也成立，虽然不具备那么大的破坏性。

当 commit() 请求从客户端向事务管理器发出，事务管理器开始两阶段提交过程。在第一阶段，所有的资源被轮询到，问它们是否准备好了提交作业。每个参与者可能回答“准备好（READY）”，“只读（READ_ONLY）”，或“未准备好（NOT_READY）”。如果有任意一个参与者在第一阶段响应“未准备好（NOT_READY）”，则整个事务回滚。如果所有参与者都回答“准备好（READY）”，那这些资源就在第二阶段提交。回答“只读（READ_ONLY）”的资源，则在协议的第二阶段处理中被排除掉。

由于 XA 环境中双向通信的能力，两阶段提交变得可能。在非 XA 事务环境中，通信仅仅是单向的，两阶段提交没法做到，这是因为事务管理器没法接收到来自资源管理器的响应。大多数事务管理器为了优化性能，尽快释放资源的目的，用多线程处理第一阶段轮询以及第二阶段提交流程。下图展示了两阶段提交的基本流程：

下图展示了当资源管理器之一（DBMS）在第一阶段轮询时发生错误的情况下两阶段提交的过程，

在这个示例中，一个提交请求被运行全局事务（global transaction，一个运行于 XA 之下的 JTA 事务）的客户端发送到事务管理器。在第一阶段，第二个资源管理器回给事务管理器一个“未准备好（NOT_READY）”响应。在本例中事务管理器对所有参与者发出回滚请求，因此协调了在全局事务中的所有资源。

一些商业的应用容器提供一种称之为“最后参与者支持（Last Participant Support）”的特性，该特性有个另外的名字叫“最后资源提交优化（Last Resource Commit Optimization）”。“最后参与者支持”允许非 XA 资源参与进全局事务。在“最后参与者支持”下，当一个 XA 环境的提交请求到达事务管理器，事务管理器会首先对 XA 资源发起第一阶段流程。一旦 XA 参与者产生的结果一致返回，事务管理器随即对非 XA 参与者发起提交（或回滚）的请求。这个请求的结果决定了两阶段提交流程剩下的工作如何进行。如果对非 XA 资源的请求成功，事务管理器会发起第二阶段，并对 XA 参与者发起提交请求。如果对非 XA 参与者的请求不成功，事务管理器会发起第二阶段，并要求所有 XA 参与者回滚事务。

“最后参与者支持”机制存在两个问题。第一，它不是在应用容器间可移植的。第二，因为在第一阶段轮询过程和非 XA 最后参与资源提交之间有较长的时间等待，您会发现在使用这一特性时发生经验异常（Heuristic Exception）的几率增加了（将会在下一节详述）。基于这些原因，“最后参与者支持”特性应该在一般情况下避免使用，除非迫不得已。

大多数商业应用服务器还支持另一个优化，称之为“一阶段提交优化（One-Phase Commit Optimization）”。如果事务只包括一个参与者，第一阶段处理会被忽略，单一的参与者被通知提交。在这种情况下，整个 XA 事务的后果取决于单一参与者的结果。

经验异常（Heuristic Exception）处理

在两阶段提交的过程，资源管理器可能会使用“经验化决策”的策略，或者提交，或者回滚它自己的工作，而不受事务管理器的控制。“经验化决策”是指根据多种内部和外部因素做出智能决定的过程。当资源管理器这么做了，它会向客户端报上一个经验异常（Heuristic Exception）。

所幸的是，经验异常并不是特别常见。它仅仅发生在 XA 环境下，做两阶段提交的过程中，特别是事务参与者在第一阶段产生了响应之后。经验异常最常见的原因是第一阶段和第二阶段之间的超时情况。当通讯延迟或丢失，资源管理器或许要做出提交或回滚其工作的决定，以释放资源。不出意料，经验异常发生最频繁的时候正是高资源利用时间段。当您在应用中发现经验异常时，您应该查找是否有事务超时问题，资源锁定问题，以及资源使用过量问题，这些问题常常是经验异常的根本原因。偶尔网络延迟或网络故障也会导致经验异常。同样的，如上面的章节所述，使用“最后参与者支持”特性会导致经验异常更为频繁的发生。

JTA 暴露出的三种 JTA 经验异常为 HeuristicRollbackException，HeuristicCommitException，以及 HeuristicMixedException。我们分别用下面的场景说明之：

场景 1**：在 commit操作阶段的 HeuristicRollbackException异常 **

在此场景中，客户端在 XA 环境下执行更新操作，向事务管理器发起提交当前事务的请求。事务管理器开启两阶段提交流程的第一阶段，随即轮询资源管理器。所有资源管理器向事务管理器报告说它们已经做好了提交事务的准备。然而，在（两阶段提交流程的）第一阶段和第二阶段之间每个资源管理器独立的做出了回滚它们已完成工作的经验性决定。当进入第二阶段，提交请求被发送到资源管理器时，因为所做的工作已经在此之前回滚了，事务管理器将会向调用者报告 HeuristicRollbackException 异常。

当接受到此类异常时，常用的正确处理方式是将此异常传回客户端，让客户端重新提交请求。我们不能简单的再次调用 commit 请求，因为对数据库产生的更新已经随回滚操作从数据库事务日志中删除了。下面的序列图说明了这一场景：

第一步：第一阶段处理（准备阶段）

第二步：在第一阶段和第二阶段之间

第三步：第二阶段处理（提交阶段）

正如您从序列图中看到的，两个资源管理器回滚了他们自己的工作，虽然他们在第一阶段都向事务管理器报告了 READY 的响应。别担心这些异常因何发生，我们在后续章节会做深入探讨。

场景 2**：在 commit操作阶段的 HeuristicMixedException异常 **

在此场景中，客户端在 XA 环境下执行更新操作，向事务管理器发起提交当前事务的请求。事务管理器开启两阶段提交流程的第一阶段，随即轮询资源管理器。所有资源管理器向事务管理器报告说它们已经做好了提交事务的准备。和第一种场景不同的是，在第一阶段和第二阶段发生的间隙，有资源管理器（例如消息队列）做出了经验性的决定提交其工作，而其他资源管理器（例如数据库）做出了回滚的经验性决定。在这种情况下，事务管理器向调用者报告 HeuristicMixedException 异常。

这种情况下，非常难于选择正确的后续应对方式，因为我们不知道哪些资源提交了工作，哪些资源回滚了工作。所有目标资源因此处于一种不一致的状态。因为资源管理器彼此互不干预的独立操作，就经验性决定而言，他们之间没有任何协调和通信。解决这一异常通常需要人力介入。下面的序列图说明了这一场景：

第一步：第一阶段处理（准备阶段）

第二步：在第一阶段和第二阶段之间

第三步：第二阶段处理（提交阶段）

注意在上面的图示中，一个资源管理器提交了它的工作，而其他资源管理器选择回滚其工作。在这种情况下事务管理器将会报告 HeuristicMixedException。

对消息队列或主题使用 XA

在 XA 接口下使用的资源必须实现 javax.transaction.xa.XAResource 接口，以便自己能够加入 XA 全局事务。对于 JMS 目标（队列或主题），这可以通过在特定的应用服务器控制台或管理程序中配置完成。真正激活 XA 的部分是 JMS 连接工厂（Connection Factory）。一旦 JMS 连接工厂支持 XA，发送给 JMS 队列或主题的消息在两阶段提交过程结束之前不会被释放。在没有 XA 的情况下，不论所处的事务上下文结果如何，发送给 JMS 目标的消息会被立即释放，并可被接收者拾取。

在 WebLogic 应用服务器中，可在管理控制台的 Services|JMS|Connection Factories 配置中激活 XA 的 JMS 连接工厂。在 Transactions 这个页面，有一个名为 XA Connection Factory Enabled 的选项，经由此可以将 JMS 目标包含到 JTA 全局事务中。对于 IBM WebSphere，可在管理控制台的 Resources|WebSphere JMS Providers|Connection Factories 路径下选择使用 XA 的 JMS 连接工厂功能。勾上名为 EnableXA 的选择框就激活了 XA 的 JMS 连接工厂。

为数据库使用 XA

可通过使用 XA 版的数据库驱动来使数据库支持 XA。由于 XA 版的数据库驱动通常比非 XA 的难用许多，一个忠告是不到不得已的时候别使用 XA 驱动。

使用 XA 版的数据库驱动常会导致不可预期且难于解决的错误。例如，将非 XA 驱动替换为 XA 版驱动常常会产生难于跟踪的错误。因此，应该在项目开发和测试阶段尽早的引入 XA 驱动（，及早暴露问题并解决之）。

在使用 XA 版的数据库驱动时，可能碰到的错误种类包括本地事务错误和嵌套事务错误。当您在一个 XA 全局事务正在进行的过程中试图开启新的事务，这些错误就会产生。这种情形会在多个环境下发生，但最常见的情况是混合本地事务模型与声明式事务模型导致，以及在 XA 环境下使用存储过程的情况。

当在 XA 环境下使用存储过程，在存储过程里调用 DDL（数据定义语句，如 CREATE TABLE，BEGIN TRAN，END TRAN）常导致错误。这是最频繁导致 XA 错误的罪魁祸首，并很难修正。例如在 Oracle 中，使用 XA 时，您可能会看到下面的错误信息：

 
ORA-02089: COMMIT is not allowed in a subordinate session

如果使用非 XA 的数据库驱动，大概您不会看到这个错误，因为 DDL 语句执行的时候 JTA 事务会暂停。当看到这个错误信息，表明了您的存储过程中包含 DDL 代码，并且（由资源管理器管理的）本地事务尝试提交它的工作。

通常要从存储过程中删除既有的 DDL 语句是困难的，因为它们在那里一定有存在的理由，或者也许这些存储过程被其他应用所共享（，要删除它们牵扯面太大）。一个有效的绕开问题的做法是，调用这些存储过程之前，手工的暂停事务；而在这些存储过程返回后，继续事务。使用这个技巧会避免 XA 相关的本地和嵌套错误。然而，如果这样做，存储过程做出的修改会独立于 JTA 全局事务提交，因此违背了事务的 ACID 特性。所以说，这种做法仅仅是绕开问题，而不是解决问题。下面的代码片段展示了此技巧的细节：

 
... 
InitialContext ctx = new InitialContext(); 
TransactionManager tm = (javax.transaction.TransactionManager) 
ctx.lookup(“javax.transaction.TransactionManager”); 
Transaction currentTx = null; 
{1}
try { 
   currentTx = tm.suspend(); 
   invokeSPWithDDL(); 
} finally { 
   if (currentTx != null)
   tm.resume(); 
} 

即便在声明式事务的环境下，我们仍然可以使用 TransactionManager 去用代码方式暂停和继续事务。这个技巧能够避免 XA 环境下的 SQL 异常信息，但它没有真正的解决问题。——真正解决问题的唯一方法是在有关存储过程中删除那些犯规的 DDL 语句，或者使用支持嵌套事务的 JTA 事务服务。

总结

本章要表达的最重要的思想是，理解什么时候您真正需要使用 XA 版的数据库驱动。许多开发人员和架构师总是坚持要使用 XA 版的数据库驱动，虽然事实上不存在使用它们的合理理由。如果您需要在同一个事务中协调多个更改的资源（数据库、消息队列、主题，或者 JCA），那么毫无疑问您需要引入 XA 接口。否则，千万避开 XA。

另一条关于使用 XA 的建议是，碰到问题时别总去猜测您使用的是一个可能错误百出的 XA 数据库驱动。问题很有可能是您的应用代码或事务处理逻辑造成的，而非 XA 驱动。

关于作者

Mark Richards 是 IBM 认证的高级 IT 架构师，他在 IBM 公司从事大型系统面向服务架构的设计和架构工作，使用 J2EE 与其他技术，主要为金融行业服务。作者早在 1984 年起就加入软件行业，从开发人员做起，直至设计师、架构师。他经常在著名论坛“No Fluff Just Stuff”演讲，他从波士顿大学获取了计算机科学硕士学位，持有 SUN、IBM、BEA 的多个 Java 与架构师认证。如有关于本书的评论或疑问，尽请联系Mark 。

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。