XA事务处理

XA协议

XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下：

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; 

try {
    currentTx = tm.suspend();
    invokeSPWithDDL();
} finally {
    if (currentTx != null)
    tm.resume();
}

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

总结

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

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

二阶段提交看起来确实能够提供原子性的操作，但是不幸的事，二阶段提交还是有几个缺点的：

1、同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。

2、单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

3、数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。

4、二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

由于二阶段提交存在着诸如同步阻塞、单点问题、脑裂等缺陷，所以，研究者们在二阶段提交的基础上做了改进，提出了三阶段提交。

3PC

三阶段提交（Three-phase commit），也叫三阶段提交协议（Three-phase commit protocol），是二阶段提交（2PC）的改进版本。

与两阶段提交不同的是，三阶段提交有两个改动点。

1、引入超时机制。同时在协调者和参与者中都引入超时机制。2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

CanCommit阶段

3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。

1.事务询问 协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。

2.响应反馈 参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No

PreCommit阶段

协调者根据参与者的反应情况来决定是否可以记性事务的PreCommit操作。根据响应情况，有以下两种可能。

假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。

1.发送预提交请求 协调者向参与者发送PreCommit请求，并进入Prepared阶段。

2.事务预提交 参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。

3.响应反馈 如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。

假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。

1.发送中断请求 协调者向所有参与者发送abort请求。

2.中断事务 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。

doCommit阶段

该阶段进行真正的事务提交，也可以分为以下两种情况。

执行提交

1.发送提交请求 协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。

2.事务提交 参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。

3.响应反馈 事务提交完之后，向协调者发送Ack响应。

4.完成事务 协调者接收到所有参与者的ack响应之后，完成事务。

中断事务 协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。

1.发送中断请求 协调者向所有参与者发送abort请求

2.事务回滚 参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。

3.反馈结果 参与者完成事务回滚之后，向协调者发送ACK消息

4.中断事务 协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

2PC与3PC的区别

相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

转：https://my.oschina.net/u/138995/blog/178280