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

　　以前已经讨论过，术语“事务”被反复使用。在本文中，我们谈到的 CICS 事务是指在 CICS 区域中启动的工作，并在四字符事务 ID (tranid) 下运行。这些 tranid 是 CICS 资源定义，这些定义指定要加载的启动程序，以及在其下运行关联任务的 CICS 事务的属性。在历史上，这些都是由构建程序控制表 (PCT) 的宏定义的，但是，如今在资源定义联机 (RDO) 数据库的 TRANSACTION 定义中进行定义。在事务启动时，CICS 将隐式启动一个新任务;这是承担事务工作的初始边界。所有对可恢复资源的更新或对其他事务系统的请求现在都是此工作单元的一部分，直到在 CICS 程序内部达到一个同步点 (syncpoint)。可以在 CICS 应用程序中使用 EXEC CICS SYNCPOINT 命令显式地编码同步点，或当任务终止时隐式地达到同步点。在同步点，作为事务管理器的 CICS 将准备所有的相关资源管理器并且协调原子结果，要么为成功提交，要么在成功提交不可能时进行回滚，在这种情况下，所有可恢复的更新将回滚到工作单元开始前的状态(请参见图 4)。

　　图 4. CICS 事务

　　在特定的情形中，例如如果使用系统间分布式程序连接 (DPL) 请求，远程的 CICS 系统可以协调被连接的 CICS 事务。CICS TG 扩展了此情况，它使用扩展调用接口 (ECI) 来启动和协调 CICS 工作单元。在 CICS TG 的术语中，这称为扩展的逻辑工作单元(图 5)。请注意，在使用 DPL 请求调用 CICS 程序时，由于事务由远程系统协调，CICS 程序将不再允许执行同步点命令。

　　图 5. 扩展的工作单元

　　另外，相反的情况也是可能是;这时被调用的 CICS 事务运行于执行调用的应用程序的独立事务上下文。这称为使用 sync-on-return 运行，sync-on-return 是指 CICS 中的控制镜像事务在控制权交给调用应用程序时发送同步点(请参见图 6)。使用 sync-on-return 类型的链接还支持被调用的 CICS 程序发出 EXEC CICS SYNCPOINT 命令，因为它不从属于另一事务管理器。

　　图 6. 使用 sync-on-return 链接

　　CICS Transaction Gateway 的事务支持

　　在使用 CICS Transaction Gateway 提供从 J2EE 应用程序到 CICS 的事务集成时，由 ECI 提供底层连接性，它可以使调用应用程序(如 J2EE Servlet 或 EJB 组件)协调被调用的 CICS 事务。不过，要了解提供的功能，有必要了解 CICS TG 关于两阶段提交网络连接和可恢复日志记录的基本事务组件的事务支持。

　　在使用 ECI 协议时，需要考虑可能有两种不同的网络连接，即从 J2EE 组件到 CICS Transaction Gateway 的连接和从 CICS Transaction Gateway 到 CICS 的网络连接。有多种网络协议支持这些连接，如下所示：

　　资源适配器到 CICS Transaction Gateway： TCP/IP、SSL 或本地绑定

　　CICS Transaction Gateway 到 CICS： SNA、TCP62、TCP/IP、EXCI。

　　在 CICS Transaction Gateway 到 CICS 连接的可能选项中，对 ECI 流提供两阶段提交事务协调的协议只有 External CICS Interface (EXCI)，它是由 CICS TS for z/OS 提供、用于 MVS™ 批处理应用程序的接口，并与 MVS Resource Recovery Services (RRS) 一起提供事务支持。此支持称为 Transactional EXCI，并要求 MVS 批处理应用程序(在本例中为 CICS Transaction Gateway)和目标 CICS 区域位于同一 MVS 映像中。

　　CICS TG V6.1 的 XA 支持构建于事务 EXCI 支持之上，方法是通过新的 CICS ECI XA 资源适配器为 CICS 的请求提供全局事务支持。这为在 z/OS 平台上的 WebSphere Application Server 中运行的本地 J2EE 应用程序或在分布式平台上(例如 AIX)的 WebSphere Application Server 中运行的远程 J2EE 应用程序提供了两阶段提交全局事务支持。

　　不过，当 CICS TG 在分布式平台上运行时，仍必须使用单阶段提交连接，因此 CICS TG 需要考虑使用支持本地事务的资源管理器。