级别： 初级 Ajay Sood, 高级软件工程师, IBM
Tomohiro Taguchi, IT 专家, IBM
2009 年 9 月 24 日 
许多中间件和数据库产品都遵守 XA 协议，以便在中间件和资源管理器互相操作时，能够获得事务性功能。由于故障（如短暂的或者长期的网络故障）或者其中一个资源管理器不可用，导致事务管理器的可用性受到破坏，这样的情况是可能发生的。本文描述了一些会影响 XA 事务可用性的常见错误场景，介绍了一些方法，帮助判断您的事务管理器在出故障的情况下是否还保持较高的可用性（以及确定事务管理器保持高效的一些方法），并且介绍了一些有关资源管理器的小诀窍。
来自 IBM WebSphere Developer Technical Journal。
简介
有关在中间件环境中配置和使用 XA 的一篇早期文章 中提到，Open Group 的 X/Open Distributed Transaction Processing（DTP）模型中发布的 XA 标准定义了事物管理器、应用程序和资源管理器之间的接口，以在 DTP 环境中实现两阶段提交：
- 应用程序执行所期望的业务功能。它指定了一系列包含了资源（如数据库）的操作。应用程序对全局事务的开始和结束进行了定义，在事务界限内获取资源，并且通常决定是否提交或回滚每个事务。
- 事务管理器管理全局事务，并协调进行提交或回滚的决定，从而确保它们的原子性。在需要时（如一个组件出故障后），事务管理器还可以协调资源管理器的恢复活动。
- 资源管理器管理计算机的部分共享资源。许多其他软件实体使用资源管理器提供的服务，不时地请求访问资源。一些资源管理器管理一个通信资源。
在一个分布式、包含了遵从 XA 的资源管理器的事务环境中，应用程序尤其需要认识事物处理，这是因为有些额外的考虑因素必须包含到在这个环境中运行的应用程序中。如果资源管理器出了故障，应用程序必须知道事务管理器是如何运作的，并使用特殊的逻辑进行弥补，以应对此类故障。事务管理器要能够处理某些资源管理器的故障，而且发生这种情况时，事务管理器还要能够继续操作，这点也很重要。这一点有助于确保事务管理器的有效性，并且在一定程度上帮助简化应用程序逻辑。作为一名程序员，除了应用程序以外，您应该测试在此类环境中事务管理器的行为，这样您才能确保充分支持所需的任何特别处理。
本文展示了当资源管理器出故障时，预期的事务管理器行为。以下部分将讨论常见的故障场景、对应的 XA 错误、当相关资源管理器出故障时事务管理器的行为，以及在这些场景下，有助于事务管理器获得更高可用性的考虑因素。
资源管理器故障的常见原因
一些常见的原因会引起资源管理器故障或变得不可用，其中包括：
- 资源管理器端运行时不一致将导致事务故障。
- 资源管理器存储故障将导致资源管理器崩溃。
- 暂时或长期的网络故障将导致资源管理器不可用。
一个资源管理器会返回两个主要的 “灾难性的” XA 错误：
- XAER_RMERR：这个错误表示在事务分支中，某个资源管理器出错了。导致这种错误可能有几种情况。例如，资源管理器认为它绝不会提交分支，无法支持处于准备状态的分支资源，或者从控制线程中分离事务分支时出现错误。
- XAER_RMFAIL：这个错误表示出现了普通错误，导致资源管理器不可用。
涉及到的资源管理器在执行过程中的不同时间点都可能会出现故障。进行一个 XA 相关的请求时，事务管理器通常会检测故障。下面是一些示例案例以及相应的事务管理器的期望行为：
-
使用 A_OPEN 建立连接的同时，执行事务的进程检测到一个错误。
期望的行为：如果 XA_OPEN 出错，事务管理器要发出警告，并且继续正常运行。事务管理器不能处理指向不可用资源管理器的事务。而且不能有任何 XA 相关的流指向不可用的资源管理器。
-
启动事务前，事务管理器检测到一个错误。
期望的行为：如果流中的任何请求（如 XA_START、XA_END、XA_PREPARE等等）出现错误，那么事务也将出错。任何 XA 流都不应指向不可用的资源管理器。
-
在准备和提交进程期间，资源管理器出现故障，事务管理器检测到错误。
期望的行为：如果故障出现在提交进程完成之前，那么事务的行为将无法确定。当资源管理器再次恢复可用时，事务管理器需要能够完成事务。将由事务管理器的实现器决定执行线程是否继续重新提交请求或保持阻止状态。
您的事务管理器能保证较高的可用性吗？
下面是一些考虑因素，您可以用来考虑事务管理器，确保即使发生了灾难性的 XA 故障（如在一个分布的 XA 事务过程中，资源管理器不可用）的情况下，它还能保持高度可用：
- 从出故障到资源管理器恢复可用之前，您还能够使用事务管理器运行非 XA 事务吗？
- 您能够运行未涉及出故障的资源管理器的事务吗？
- 即使在发生故障的资源管理器持续不可用时，您能够在事务管理器中提交下一个事务而不出现问题吗？
- 资源管理器恢复可用时，包含了出故障的资源管理器的事务是否也自动解决了问题呢？
- 资源管理器恢复可用前，事务管理器的行为是什么？执行需要恢复的事务的线程或进程是否不断重试资源管理器，希望它恢复可用？
- 事务管理器是否存有旧连接？资源管理器恢复可用后，新事务的第一次调用是否会出错？
当资源管理器在不同时间点出现故障时，下面小节展示的一些测试案例可以帮助您解决这些问题，因为它们都与事务管理器相关。如果这些条件都不符合您的情况，应该与供货商商议事务管理器的功能。
面向 XA 弹性的测试案例
如果一个资源管理器失效，下面的四个测试案例能够帮您判断事务管理器是否能够在高可用性的情况下运行。所有的测试案例都有着同样的假设：
- 事务管理器要么是一个多线程环境，要么是一个多进程环境。如果是多线程环境，执行事务的单元就是一个线程（叫做执行线程或 ToE）。如果是多进程环境，执行事务的单元就是一个进程（叫作一个执行进程或 PoE）。
- 这些测试案例演示一个多进程事务管理器，因此每个事务都是在一个独立的进程中执行的。然而，即使执行单元是一个线程，期望的事务管理器行为都是相同的。目的是要说明只有执行事务的进程或线程受到了影响，而总的事务管理器不受影响，并且可用于其它类型的任务。
- IBM® DB2® 将被作为资源管理器的一个示例在此使用，在测试过程的不同阶段，状态将发生变化（可用或不可用）。事务管理器的行为应该不会受到资源管理器状态变化的影响。
- 在实验室测试过程中，应该使用 dbx 之类的调试器（在 AIX® 上）在某个点强行停止或启用 PoE。进行这些测试时，您可以使用自己选择的工具或方法。
案例 1：执行事务时，资源管理器出故障
情景：在执行使用资源管理器的事务时，资源管理器不可用。请参见图 1。
测试：
- 事务管理器在运行并且可用。
- 事务管理中的一个进程执行一个 DB2 相关的事务。
- 在执行事务期间，关闭 DB2。
- 事务发出一个提交或回滚（xa_commit 从进程中流出）。
- 由于 DB2 不可用，事务（以及进程）遇到一个 xa_error（XAER_RMERR）。
- 执行事务的进程用其所期望的方式处理错误（例如，重启执行事务的进程）。
- 检测行为：
- 确保事务管理器总体上保持可用，即使进程检测到了故障，也只有执行事务的那个进程受到影响。
- 一旦发生了如 XAER_RMERR 之类的故障，如果事务管理器的行为是要重启进程，那么检测重启的执行进程（图 1 中的 PoE（1））是否在重试，直到出错的事务恢复为止。出错的资源管理器恢复可用时，事务也将恢复。只有在出故障的事务需要恢复时才需要执行这个检测。
- 在特定的 DB2 实例恢复可用之前，包含了出错的 DB2 实例的其他事务可能会出现故障。
- 即使出错的 DB2 实例持续不可用，没有包含 DB2 的事务应该能够继续正常运行。
- 启用 DB2，使其可用。
- 所有重新提交的事务应该能够再次正常运行。
这个测试有助于验证 问题 c、d 和 e。
图 1. 案例 1
案例 2：连接到一个进程时，资源管理器出现故障
情景：执行进程连接到资源管理器。资源管理器崩溃。提交一个包含了出错的资源管理器的事务。请参见图 2。
测试：
- 事务管理器正在运行中而且可用。
- 执行事务的进程连接到了 DB2。没有事务在运行。
- 关闭 DB2。
- 运行一个没有包含 DB2 的事务。事务应该正常执行。
- 运行一个包含了 DB2 的事务。事务应该会失败，并且出现一个 SQL 错误。
- PoE 应该处理错误，并采取相应动作。
- 检测行为：
- 启用 DB2。
- 激活一个包含了 DB2 的事务。新的事务开始运行时，发出 XA_OPEN，并建立一个连接。事务应该正常执行。
这个测试有助于验证 问题 a。
图 2. 案例 2
案例 3：资源管理器出现故障后，进程保持旧的处理
情景：资源管理器崩溃。恢复可用后，提交一个涉及到资源管理器的事务。请参见图 3。
测试：
- 事务管理器正在运行。
- 执行事务的进程使用 XA_OPEN 连接到 DB2。
- 关闭 DB2。
- 没有包含 DB2 的事务应该在正常运行。
- 启用 DB2。
- 提交一个包含了 DB2 的事务。检查应用程序是否由于 PoE 中的一些旧连接导致了连接错误。
- 检查行为：
- 在一些事务管理器中，由于旧的处理导致错误后，PoE 会进行重启，然后建立一个新的连接，并且重新提交事务。这意味着为了去除旧的连接处理，PoE 需要进行循环运行。
这有助于验证 问题 f。
图 3. 案例 3
案例 4：使用不可用的资源管理器启动进程和提交事务。
情景：资源管理器不可用时，启动一个 PoE。资源管理器不可用时，提交一个事务。请参见图 4。
测试：
- 事务管理器可用。
- DB2 不可用。
- 启动一个新的 PoE。XA_OPEN 失败。
- 提交一个包含了指向 DB2 的 SQL 语句的事务。DB2 不可用时，会遇到 SQL 错误。没有 ax_reg 在流动（在动态注册的情况下）。由于没有对不可用的 DB2 发出 XA 请求，回滚应该会正确运行（这个特定的 DB2 还没有被作为参与的 XA 资源管理器进行注册）。
- 检测行为：
- 非 SQL 事务（和没有包含 DB2 的事务）应该能继续正常运行。
- 启用 DB2。
- 提交一个包含了 DB2 的事务。用 DB2 建立连接，并且事务应该成功运行。
这个测试有助于验证 问题 b。
图 4. 案例 4
保护您的事务管理器，防止其受到资源管理器影响
下面是一些设计考虑因素，可以使您的事务管理器灵活应对资源管理器故障：
- 确保将不可用的资源管理器标记为对事务管理器不可用，并且事务管理器能够继续与其他的资源管理器一起运行。
- 事务管理器应该能够继续处理没有包含出错资源管理器的事务。
- 即使参与事务的一个资源管理器发生了灾难性的错误，事务管理器应该仍然可用。
- 事务管理器应该在资源管理器可用时，能够检测到其可用性。
- 事务管理器应该能够在出错的资源管理器恢复可用时解决出错的事务。
- 事务管理器应该能够在出错的资源管理器可用时，继续运行包含了出错的资源管理器的新事务请求。
- 要把旧的连接从事务管理器的缓存中移除，这样的话，资源管理器恢复可用后的第一个事务调用就不会出错。
最后，介绍一些小诀窍，可以帮助您使用一些流行的资源管理器：
- 对于 IBM WebSphere® MQ 来说，只有发布了具有同步点选项的 MQPUT，ax_reg 才会流向事务管理器。这意味着如果把 WebSphere MQ 设置为动态注册，而且错误出现在具有同步点的 MQPUT 之前，WebSphere MQ 可能就不支持 XA 弹性功能。
- 使用除 DB2 以外的一些流行的资源管理器时，如果在 xa_end 的过程中出错，将会返回 XAERR_PROTO，而不是 XAERR_RMERR。事务管理器要能够容忍不同资源管理器在发生类似错误时返回的不同错误代码而导致的不同行为。
结束语
在当今的企业中，如果核心系统的可用性非常关键的话，那么诸如事务管理器之类的核心组件在其他相关组件出错时还能保持可用性，这点非常重要。本文中的测试案例能够帮助您提前判断企业系统中的事务管理器是否对某些类型的错误具有灵活的应变能力。
参考资料
作者简介  | | | Ajay Sood 是位于印度 Bangalore 的一名 IBM 高级软件工程师。他效力于 IBM 已经超过了 13 个年头，一直都是产品开发（如 DB2 DataLinks 和 TXSeries-CICS）团队的开发人员。他拥有事务处理、中间件，以及在 UNIX 平台上进行系统编程的工作经验。 |
| | | Tomohiro Taguchi 是位于日本 Makuhari 的 IBM Japan Systems Engineering Co.,Ltd 的一名 IT 专家。他主要进行 CICS 系列产品（如 TXSeries 和 CICS Transaction Gateway）的技术支持。 |
对本文的评价
| 
