利用J2EE Connector Architecture(2)

两阶段提交

分布式事务处理的基本部分是两阶段提交进程。这是流的体系结构集，用于确保无论发生什么故障，事务中的所有资源管理器都能够可靠地协作。两阶段提交由所有事务协议实现，并且基本概念在本质上是相同的。以下描述根据 XA 规范总结了流；其他协议（如 CICS 或 LU6.2）可能对流使用不同的术语和变体。（有关 CICS 同步点流的进一步详细信息，请参阅《CICS Intercommunication Guide》，SC34-6243，第 2 章“Recovery and restart in interconnected systems”。）

在两阶段提交进程之前，事务过程中执行的所有工作都被认为是“在处理中”，并且在此期间如果失败将会导致工作回滚。只有在事务管理器启动两阶段提交进程时，更新才会变得确定。

图 2. 两阶段提交

在两阶段提交进程的第一个阶段中（或称阶段 1）：

事务管理器请求所有资源管理器准备提交可恢复资源（准备）。

每个资源管理器可以积极表决（已准备）或消极表决（已回滚）。如果资源管理器积极应答，则它稳定地记录需要这样做的信息，应答已准备，然后必须遵循下一个阶段确定的事务的最终结果。

现在可以将资源管理器描述为“未确定”，因为它已将事务的最终结果指派给事务管理器，现在还不知道事务的实际结果。

在第二个阶段（或称阶段 2），假设所有资源管理器都积极应答：

事务管理器使用提交流应答每个资源管理器。然而，如果资源管理器未能应答，则在假定事务应中断之前，事务管理器可以重新传输准备流。

在接收提交流之后，资源管理器完成对可恢复资源的更新，并释放对资源或打开的文件所持有的任何锁。

资源管理器然后使用最终提交的流进行响应，指示事务管理器不再处于未确定状态。

如果事务管理器没有收到最终提交的流，则事务管理器必然假定提交未到达资源管理器，因此需要重新传输提交，直至收到积极回复。

如果在提交过程中事务管理器失败，则事务可能在资源管理器中处于未确定状态。在重新启动后，事务管理器将与资源管理器重新同步，以发现事务的状态，然后继续执行提交过程，并根据需要提交事务或退回事务。

最后的参与者支持

在 J2EE 事务环境中，WebSphere Application Server 的最后的参与者支持功能扩展了全局事务模型，可以支持一个单阶段提交资源参与具有任何数量的两阶段提交能力的资源的全局事务。在事务提交时，应用程序服务器首先准备两阶段提交资源管理器，如果成功，则调用单阶段提交资源进行提交。然后，两阶段提交资源或者提交或者回滚，具体取决于来自单阶段提交资源的响应。此过程有效地指派了对单阶段提交资源的事务协作。

图 3. 最后的参与者支持

与两阶段提交进程不同，单阶段提交资源在通信失败时无法恢复。因此，在提交单阶段提交资源时通信失败会带来混合的事务结果风险（启发式危险）。两阶段提交资源可以回滚，但单阶段提交资源的结果是未知的，它可能已提交或者已回滚。因此，必须将应用程序配置为接受此类启发式结果的额外风险，下文对此进行了详细说明。

利用J2EE Connector Architecture(3)

CICS 工作单元：事务、任务和同步点

以前已经讨论过，术语“事务”被反复使用。在本文中，我们谈到的 CICS 事务是指在 CICS 区域中启动的工作，并在四字符事务 ID (tranid) 下运行。这些 tranid 是 CICS 资源定义，这些定义指定要加载的启动程序，以及在其下运行关联任务的 CICS 事务的属性。在历史上，

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!