X/Open 分布式事务处理模型

应用程序 (AP)

应用程序 (AP) 定义事务边界以及那些组成事务的特定于应用程序的操作。

例如，CICS® 应用程序可能要访问诸如数据库和 CICS 瞬时数据队列之类的资源管理器 (RM) 以及使用编程逻辑来处理数据。每个访问请求都会通过特定于该 RM 的函数调用来传递至相应资源管理器。对于 DB2® 产品，这些函数调用可以是 DB2 数据库预编译器为每个 SQL 语句生成的函数调用，也可以是由程序员通过 API 直接用代码编写的数据库调用。

事务管理器 (TM) 产品通常包括事务处理 (TP) 监视器，以运行用户应用程序。TP 监视器提供 API，以允许应用程序启动和结束事务以及在要运行该应用程序的许多用户之间执行应用程序调度和负载均衡。分布式事务处理 (DTP) 环境中的应用程序实际上是用户应用程序与 TP 监视器的组合。

为了使联机事务处理 (OLTP) 环境更高效，在启动时 TP 监视器会预先分配大量服务器进程，然后在许多用户事务之间对它们进行调度和复用。允许支持较多并行用户使用较少量服务器进程及其相应 RM 进程，这会节省系统资源。复用这些进程还会避免在 TM 和 RM 中为每个用户事务或程序启动进程的开销。（程序会调用一个或多个事务。）这还意味着，对于 TM 和 RM，这些服务器进程是实际的“用户进程”。这同安全性管理和应用程序编程有关。

下列类型的事务可能源自 TP 监视器：

• 非 XA 事务

  这些事务涉及未对 TM 定义的 RM，因此，没有通过 TM 的两阶段落实协议进行协调。如果应用程序需要访问不支持 XA 接口的 RM，那么这可能有必要。TP 监视器仅提供高效的应用程序调度和负载均衡。因为 TM 不会显式“打开”RM 以进行 XA 处理，所以 RM 将此应用程序视为非 DTP 环境中运行的任何其他应用程序。

• 全局事务

  这些事务涉及对 TM 定义的 RM 并且处于 TM 的两阶段落实控制下。全局事务是可涉及一个或多个 RM 的工作单元。事务分支是 TM 与支持全局事务的 RM 之间的工作部分。当通过由 TM 协调的一个或多个应用程序进程访问多个 RM 时，全局事务可具有多个事务分支。

  如果大量应用程序进程中的每个进程访问 RM 时，就好象它们处于单独的全局事务中一样，但是这些应用程序处于 TM 的协调下，那么存在松散耦合的全局事务。每个应用程序进程在 RM 中都将具有它自己的事务分支。当其中任何一个 AP、TM 或 RM 请求落实或回滚时，这些事务分支都会一起完成。确保在这些分支之间不出现资源死锁是应用程序的职责。（请注意，DB2 事务管理器为备有选项 SYNCPOINT(TWOPHASE) 的应用程序执行的事务协调大致相当于这些松散耦合的全局事务。

  如果 多个应用程序进程在 RM 的同一事务分支下依次进行工作，那么存在紧密耦合的全局事务。对于 RM，这两个应用程序进程是单个实体。RM 必须确保在事务分支中不出现资源死锁。

事务管理器 (TM)

事务管理器 (TM) 将标识指定给事务，监视它们的进度并对事务的完成和失败负有责任。事务分支标识（称为 XID）由 TM 指定，以在 RM 中标识全局事务和特定分支。这是 TM 中日志与 RM 中日志之间的关联标记。两阶段落实或回滚需要 XID，以在系统启动时执行再同步操作（也称为再同步）或在必要时让管理员执行启发式操作（也称为手动干预）。

在 TP 监视器启动之后，它会要求 TM 打开一组应用程序服务器已定义的所有 RM。TM 会将 xa_open 调用传递至这些 RM，以便能够初始化这些 RM 来进行 DTP 处理。作为此启动过程的一部分，TM 会执行再同步以恢复所有不确定事务。不确定事务是处于不确定状态的全局事务。在成功完成两阶段落实协议的第一阶段（即，准备阶段）之后，当 TM（或至少一个 RM）不可用时，会出现此情况。直到当 TM 与 RM 再次可用之后 TM 可以解决它自己的日志与 RM 日志之间的冲突时，RM 才将知道是要落实还是回滚其事务分支。为了执行再同步操作，TM 对其中每个 RM 发出 xa_recover 调用一次或多次，以识别所有不确定事务。TM 会将应答与它自己日志中的信息进行比较，以确定是否应该通知 RM 对这些事务执行 xa_commit 或 xa_rollback。如果 RM 通过其管理员的启发式操作已落实或回滚其不确定事务分支，那么 TM 会对该 RM 发出 xa_forget 调用以完成再同步操作。

当用户应用程序请求落实或回滚时，它必须使用 TP 监视器或 TM 提供的 API，以便 TM 能够在涉及的所有 RM 之间对落实和回滚进行协调。例如，当 WebSphere® 应用程序发出落实事务的请求时，WebSphere XA TM 将反过来发出 XA 调用（例如 xa_end、xa_prepare、xa_commit 或 xa_rollback）以请求 RM 落实或回滚该事务。如果仅涉及一个 RM 或 RM 的应答指出其分支为只读，那么 TM 可选择使用一阶段落实而不是两阶段落实。

资源管理器 (RM)

资源管理器 (RM) 提供对诸如数据库之类的共享资源的访问。

作为数据库的资源管理器的 DB2 系统可参与由 XA 兼容的 TM 进行协调的全局事务。按 XA 接口的要求，数据库管理器提供类型为 xa_switch_t 的 db2xa_switch 外部 C 变量来将 XA 切换结构返回至 TM。此数据结构包含要由 TM 调用的各个 XA 例程的地址以及 RM 的操作特征。

RM 可使用以下两种方法来注册其在每个全局事务中的参与：静态注册和动态注册：

• 静态注册要求 TM 对为服务器应用程序定义的所有 RM 发出（针对每个事务）xa_start、xa_end 和 xa_prepare 系列调用，不管事务是否使用给定 RM。如果并非每个 RM 都参与每个事务，那么此方法的效率很低，低效程度与所定义 RM 的数目成比例。
• 动态注册（由 DB2 使用）灵活且高效。仅当 RM 接收到对其资源的请求时，该 RM 才使用 ax_reg 调用向 TM 进行注册。请注意，甚至当仅定义了一个 RM 或每个 RM 都由每个事务使用时，此方法都不存在性能缺点，因为 ax_reg 和 xa_start 调用在 TM 中具有相似路径。

XA 接口在 TM 与 RM 之间提供双向通信。它是这两个 DTP 软件组件之间的系统级别接口，而不是应用程序开发者对其进行编码的普通应用程序接口。但是，应用程序开发者应该熟悉这些 DTP 软件组件强制执行的编程限制。

虽然 XA 接口不变，但是 XA 兼容的每个 TM 都可具有特定于产品的方法以集成 RM。有关将作为资源管理器的 DB2 产品与特定事务管理器集成的信息，请参阅相应 TM 产品文档。