引言 CICS 应用程序与事务的服务质量有同等含义；将这些应用程序与主流 J2EE 组件集成在一起是当今许多企业面临的共同难题。可以使用 J2EE Connector Architecture (JCA) 和 CICS Transaction Gateway 提供对 WebSphere Application Server 中部署的 CICS 应用程序和 J2EE 组件的事务集成。 为了向您介绍如何实现这一集成，我们将从概述基本事务概念开始，然后具体介绍以下软件中的事务环境：IBM WebSphere Application Server、CICS Transaction Server for z/OS™ (CICS TS) 和 CICS Transaction Gateway (CICS TG)，其中包括 CICS TG V6.1 for z/OS 中新的 XA 两阶段提交支持。我们将详细分析 WebSphere Application Server 中的 Servlet 和 EJB 组件的事务控制，并阐述如何使用这些控制来提供 WebSphere Application Server 中部署的应用程序与 CICS 之间的不同级别的事务集成。 本文的目标读者是需要了解将 JCA 和 CICS 一起使用的事务本质的应用程序设计人员和架构师。本文假设您了解 CICS 和 JCA 方面的基础知识。 事务为何物？ 在 J2EE 世界里，事务是活动单元，在活动单元内，把可恢复的资源的多次更新作为原子性的（更确切地说，一个不可分割的工作单元），以使得要么全部更新要么全不更新。然而，在 CICS 世界里，事务是指被特定的事务标识符 (transaction-identifier) 调用的通过一个 CICS 程序（或一系列的程序）完成的工作，并且运行在一个特定的 CICS 任务下。该 CICS 任务本身由多个可恢复的工作单元（也被称为逻辑工作单元）组成，这些工作单元通过同步点区分。这些工作单元是一些可恢复的原子单元，因此它们类似于 J2EE 世界的事务。 基本组件 在事务环境中，所有参与者都被划分为资源管理器或事务管理器。资源管理器负责管理可恢复数据，例如文件或队列。事务管理器负责事务响应，并且在多个资源管理器之间协调事务的结果。在它们之间，事务管理器和资源管理器负责可靠地协调对可恢复资源的更新，以便维护原子性、一致性、隔离性和持久性之类的事务规则。为实现此目标，有必要为每个参与者实现一个共同的体系结构标准。在下面的部分中，我们将简要介绍下列标准和协议： J2EE Connector Architecture (JCA) 两阶段提交。 JCA 是 J2EE 标准的一部分，并指定由资源适配器实现的系统契约。这些系统契约定义资源适配器为事务管理、连接管理和安全提供的服务质量（图 1）。 图 1. JCA 系统契约
在 J2EE 体系结构中，分布式事务称为全局事务，管理可恢复资源的系统称为资源管理器，示例有 CICS、IMS™ 和 DB2®。这些资源管理器基于它们支持的事务分类，它们或者支持两阶段协作（通过提供 XAResource 接口）、或者仅支持单阶段协作（通过 LocalTransaction 接口）、或者为非事务管理器。 对于事务管理，资源适配器需要实现下列契约之一，这在资源适配器的部署描述符中进行了定义（ra.XML 文件）： XA 事务——可以完全参与两阶段提交进程的资源适配器，该资源适配器可以影响全局事务的结果。 LocalTransaction——可以参与资源管理器本地事务的资源适配器（在我们的示例中是 CICS 区域），但该资源适配器不具有任何两阶段提交事务功能。为便于清楚地说明，在本文中（以及在其他与 WebSphere 相关的出版物和论文中），我们使用术语资源管理器本地事务 (RMLT) 来表示位于单个资源管理器本地的事务。 NoTransaction——指无事务属性的资源适配器；它可以参与事务上下文，但不受事务结果的影响（也不影响事务的结果）。 WebSphere Application Server 事务支持为事务中任何数量的具有两阶段功能（XA 事务）的资源管理器提供协作。它还允许在事务中没有任何其他资源管理器的情况下使用一个具有单阶段功能的（本地事务）资源管理器。 两阶段提交 分布式事务处理的基本部分是两阶段提交进程。这是流的体系结构集，用于确保无论发生什么故障，事务中的所有资源管理器都能够可靠地协作。两阶段提交由所有事务协议实现，并且基本概念在本质上是相同的。以下描述根据 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. 最后的参与者支持
与两阶段提交进程不同，单阶段提交资源在通信失败时无法恢复。因此，在提交单阶段提交资源时通信失败会带来混合的事务结果风险（启发式危险）。两阶段提交资源可以回滚，但单阶段提交资源的结果是未知的，它可能已提交或者已回滚。因此，必须将应用程序配置为接受此类启发式结果的额外风险，下文对此进行了详细说明。 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 需要考虑使用支持本地事务的资源管理器。 CICS 资源适配器 CICS TG 现在支持能够用于从支持的 J2EE 应用程序服务器到 CICS 的出站通信的三种不同的 JCA 资源适配器： CICS ECI 资源适配器——此资源适配器实现 LocalTransaction 接口，并提供对资源管理器的本地事务的支持（其中，事务位于单个资源管理器本地，例如 CICS 区域）。JCA 1.0 和 1.5 版可以分别与 J2EE V1.3 和 J2EE V1.4 应用程序服务器一起使用。此资源适配器随 z/OS 和多平台上的 CICS Transaction Gateway 一起提供，并且可以与任何平台上任何版本的 CICS 一起使用。 CICS ECI XA 资源适配器——此资源适配器实现 XA 事务支持，而且完全支持全局两阶段提交事务。该适配器仅在 JCA 1.5 版中提供，并随 CICS Transaction Gateway v6.1 for z/OS 一起提供，在 WebSphere Application Server V6 中与 CICS TG for z/OS 和 CICS TS for z/OS 一起使用。 CICS EPI 资源适配器——此资源适配器可用于访问基于 3270 终端的程序。由于它基于 CICS 3270 接口这一特性，因此不提供全局事务支持，所以不应将其用于 CICS 应用程序的事务集成。同时提供了 JCA 1.0 和 1.5 版本，但它只能用于多平台上的 CICS Transaction Gateway。 z/OS 平台上 WebSphere Application Server 中的 RRS 事务支持 当使用 WebSphere Application Server for z/OS 时，CICS ECI 资源适配器通过使用附加的 RRS 事务模式支持全局事务。当使用本地网关时，将自动利用此 RRS 事务模式。使用本地网关是由 CICS ECI 连接工厂 ConnectionURL 参数中的“local”设置表示的，它指定在 WebSphere Application Server JVM 中资源适配器应直接调用 CICS Transaction Gateway EXCI 接口，因此省去了对独立网关的需求。此共存方法提供了两方面的性能优势，减少了 MVS Resource Recovery Services (RRS) 两阶段提交处理的路径长度和指派。 在使用 CICS ECI 资源适配器或 CICS ECI XA 资源适配器时可提供 RRS 事务支持，并且运行于 WebSphere Application Server V5、V5.1 或 V6 的 JCA 1.0 和 JCA 1.5 资源适配器也提供该支持。 WebSphere Application Server 中的事务支持 WebSphere Application Server 可以为不同类型的 J2EE 组件提供不同的服务质量。这可以通过使用一组隔离的运行时环境（称为容器）实现。这四个容器分别是 Web 容器、EJB 容器、客户端容器和 Applet 容器。在 WebSphere Application Server V5 和 V6 中，JCA 支持是通过 Web 容器和 EJB 容器提供的，这两种容器都支持 JCA 连接池机制和来自 J2EE 组件的事务上下文的传播。 Web 容器 Web 容器的主要功能是针对 Servlet 和 JSP 组件，但是它也提供全局事务支持。然而，Web 容器不提供容器管理的事务服务，但是如果需要，可以通过应用程序以编程方式来控制事务范围。可以通过调用从 ConnectionFactory 获取的 Connection 对象上的 getLocalTransaction() 方法控制资源管理器的本地事务；这提供了特定于 JCA 连接工厂（即 CICS 区域）的单一实例的单阶段提交事务上下文。还可以通过使用 Javax.transaction.UserTransaction 接口创建两阶段提交事务上下文来开始和结束事务。此类应用程序必须在 HTTP 请求的生命周期内提交事务。不可能（或不值得）跨多个对 Servlet 的 HTTP 请求扩展事务的生命周期，而且 WebSphere Application Server 回滚在 Servlet service() 方法结束时还没有结束的任何全局事务。 EJB 容器 EJB 容器提供对全局事务的完整事务支持，包括容器管理的事务 (CMT) 和 Bean 管理的事务 (BMT)。会话 Bean 和消息驱动的 Bean 可以使用任一种类型。实体 Bean 仅限于使用 CMT。使用 BMT 的 Bean 负责事务划分并且必须使用 UserTransaction 接口来开始和结束事务。CMT 是首选的机制，因为它把事务控制委托给应用程序服务器，使应用程序开发人员能够专注于开发业务逻辑，同时仍可以根据部署决定应用程序的事务特性。CMT 的事务控制的关键是 EJB 事务属性，下面将讨论该属性。 事务属性 事务属性在 EJB 部署描述符（ejb-jar.xml 文件）中设置，事务属性是控制属性，在控制情形下当调用 Bean 方法时启动全局事务。此事务属性显示在“container-transaction”部分，并使用“trans-attribute”标记指定。例如，以下 XML 定义 CTGTesterCCI Bean 上的远程 execute() 方法具有“Required”事务属性：
图 7 显示了如何使用 IBM Rational® Application Developer 中的 EJB 部署描述符编辑器定义这些设置的情况。 图 7. Rational Application Developer 中的事务属性
事务属性的可能值及其描述在表 1 中列出： 表 1. EJB 事务属性
本地事务容器 EJB 2.0 规范没有指定如果在没有全局事务下运行方法时容器的行为。Servlet、使用 Bean 管理的事务的会话 Bean 和一些其他情况会发生这种现象。在该种情况下，应用程序被请求在“未指定的事务”上下文中执行。为了实现一致性和可移植性，WebSphere Application Server 使用本地事务容器 (LTC) 策略执行该未指定的事务上下文。此 LTC 策略是一种有效的划定范围的方法，Web 和 EJB 容器可以使用此方法划分在全局事务外分配的工作的开始和结束。在该 LTC 内对资源管理器的所有访问都通过资源管理器本地事务 (RMLT)，在 LTC 结束时必须解决这种事务。没有办法以编程方法与 LTC 范围进行交互；并且 LPC 范围影响 J2EE 应用程序的方法由三个扩展的部署描述符 (XDD) 控制，这三个部署描述符可以在 J2EE 组件部署时设置，如下所示： Boundary——它可以有值 BeanMethod（缺省）或 ActivitySession。ActivitySession 是对仅仅在 WebSphere Application Server EntERPrise Version 5 中适用的 EJB 容器的扩展。它在基于资源管理器的本地事务的边界方法之外提供了一个扩展的工作单元范围。（有关详细信息，请参见 Transactional services in WebSphere Application Server Enterprise V5, REDP3759。） Resolver——这个可以有值 ContainerAtBoundary 或 Application（缺省）。当在全局事务上下文（例如带有 Never 事务属性）外面的 EJB 容器发出 ECI 请求时，如果 Resolver 属性被设置为 Application，那么 ECI 调用类型是非扩展的。相反，如果 Resolver 属性被设置为 ContainerAtBoundary，那么将会启动资源管理器本地事务，且 ECI 调用类型是扩展的，会被容器在 EJB 方法的边界解决。 UnresolvedAction——它可以具有值 Commit 或 Rollback（缺省）。它可以被指定用于 EJB 或 Web 容器，并表示容器如何使用 LTC 边界上未完成的 RMLT 来清除所有的连接。该属性是 Web 组件 (Servlet) 唯一可配置的 LTC 设置，通过在连接上使用 LocalTransaction.begin() 方法应用于 Bean 管理的事务。在交互完成后，所有的容器管理事务被自动提交，因此在 Web 容器中容器管理的事务不使用该属性。 有关 LTC 策略的使用需要注意以下几点： LTC 范围对于每个 J2EE 组件而言都是本地的；因此如果在 LTC A 下分派 EJB 组件 A，并且该组件调用 EJB 组件 B，那么需要在一个单独的 LTC 下分派组件 B。 如果应用程序在全局事务外执行，那么容器始终会建立 LTC 范围，除非 Web 组件或 BMT 企业 Bean 是 J2EE 1.3 以前的标准。 事务部署场景 在这一部分，我们将解释把 Servlet 和 EJB 组件部署到 WebSphere Application Server 环境中的事务本质，以及有效利用事务控制的方法。对于 Web 容器和 EJB 容器两个环境，我们给出了一组常见问题，并且提供了所提出的问题或场景的实际解决方案： 在同一事务范围内，Servlet 能否发出多个 ECI 请求？ 如何链接到发出 SYNCPOINT 命令的 CICS 程序？ 在同一事务范围内，EJB 组件能否发出多个 ECI 请求？ 怎样发出对全局事务的 CICS 部分的 ECI 请求？ 如果使用 z/OS 平台上的 WebSphere Application Server，事务支持有什么不同？ 在 z/OS 上部署 CICS TG 的好处是什么？ 如果在两阶段提交处理过程中出现网络连接故障，会发生什么情况？ 是否存在单阶段提交协议比两阶段提交协议更有好处的情况？ 如果在全局事务中使用具有本地事务能力的资源适配器（如 CICS ECI 资源适配器），则会发生什么故障？ 如果在 WebSphere Application Server 中使用 ECIRequest 类或 Common Connector Framework (CCF) 类，可以提供什么支持？ 如果 CICS 区域或事务出现意外故障，会发生什么情况？ 部署到 Web 容器 在 Web 容器中部署的 Servlet 组件缺乏 EJB 组件的大多数事务属性。尽管如此，Web 容器还是支持 RMLT 和 LTC 容器策略，使用这两个策略可以影响 ECI 资源适配器发出的 JCA 请求。 在同一事务范围内，Servlet 能否发出多个 ECI 请求？ 如果在一个交互中两次调用 execute() 方法，这样会调用两个相应的到 CICS 的 ECI 调用，两者都使用 CICS SYNCONRETURN 选项进行链接。下面的代码示例说明了该方法：
不过，与其在同一事务上下文下运行两个对 CICS 的请求，还不如它们各自在 CICS 中作为独立的工作单元运行，并使用单独的 CICS 镜像事务实例。这是因为在 Web 容器内部，在后续请求发出之前，每个交互都是自动提交的。 如果您需要两个这样的对 CICS 的请求在同一事务范围内运行，那么有两种解决方案可以考虑。第一个建议的方法是使用 EJB 容器的事务控制（请参见问题 3），第二个方法是以编程方式创建并控制 Bean 管理的事务 (BMT) 的事务范围。通过任何版本的 CICS Transaction Gateway 并使用连接工厂的本地事务支持可以完成此操作，如下面的代码示例所示：
当控制这样一组交互时，事务上下文对于 Connection 对象而言是本地的，因此对于基础的 ConnectionFactory 和它引用的 CICS 区域而言也是本地的。只要多个请求都在相同的 CICS 上启动，并通过相同的 CICS Transaction Gateway 访问，就可以对 CICS 发出多个请求。 如果需要对多个资源管理器（如两个不同的 CICS 系统）进行更新，则需要全局事务上下文。这有必要使用 CICS ECI XA 资源适配器和 CICS Transaction Gateway V6.1 for z/OS。必须使用 Java Transaction API 和 UserTransaction 接口控制 BMT，该接口可以提供跨多个连接的必要 XA 事务支持（如果需要）。
如何链接到发出 SYNCPOINT 命令的 CICS 程序？ 发出 SYNCPOINT 命令（带有或不带有回滚选项）的 CICS 程序不能从属于另一个事务管理器，因此它也不能成为扩展或全局事务的一部分。此事务管理器可以是发出 DPL 请求的另一个 CICS 系统，在我们的示例中是向 CICS ECI 资源适配器发送 CCI 请求的 WebSphere Application Server 事务管理器。此限制的原因是链接的程序在全局事务中是有效的资源管理器，并且只有事务管理器（初始调用方）可以控制事务协调。 因此，要链接到发出 SYNCPOINT 命令的 CICS 程序，必须在 LINK 命令上指定 SYNCONRETURN；这意味着 CICS 服务器程序将在独立于客户机的本身的工作单元中运行。通过将 CICS ECI 资源适配器与 WebSphere Application Server 结合使用，可以动态地控制在 CCI 调用上使用 SYNCONRETURN 行为。对于来自 Web 容器中 Servlet 的调用，带有 SYNCONRETURN 的 LINK 是缺省的请求行为（请参见问题 1），而在 EJB 容器中，可以通过在 EJB 事务属性上定义非事务属性（如 Never）来利用容器，如表 2 所示。 使用此 SYNCONRETURN 选项非常有用，因为通过远程事务管理器（在我们的示例中是 WebSphere Application Server）它可以从任何事务控制中释放 CICS 程序，并将事务的结果指派给 CICS。出于应用程序设计原因，这有时是非常必要的，只要 CICS 本身在管理所有可恢复的更新（如通过 CICS/DB2 或 CICS/VSAM 进行的更新），仍可以维护 CICS 中的事务完整性。 部署到 EJB 容器 WebSphere Application Server 中的 EJB 容器完美地适合于事务组件的部署，并且提供对容器和 Bean 管理事务两者的支持。容器管理的事务具有这样的优势：J2EE 服务器执行所有的事务协调，而用程序开发者可以集中精力开发业务逻辑而不是事务逻辑。为了控制事务组件的行为，EJB 容器提供了一组用于控制容器管理组件的事务行为的属性。在这一部分中，我们将介绍这些属性并且阐释如何与 CICS ECI 资源适配器一起使用它们。 在同一事务范围内，EJB 组件能否发出多个 ECI 请求？ 事务属性和事务上下文的初始存在都会影响 ECI 调用类型和对 CICS 调用最后得到的事务范围。表 2 描述了 CICS 镜像任务最后所得到的 ECI 调用类型和事务范围。长时间运行的 CICS 镜像任务需要 CICS 中扩展的工作单元，尽管 synconreturn 选项的镜像任务意味着 CICS 事务运行在相对于 EJB 组件的上下文而言独立的事务上下文，并在各个 ECI 调用结束后镜像任务终止。 表 2. EJB 事务属性的 ECI 调用类型
怎样发出对全局事务的 CICS 部分的 ECI 请求？ 有四个方法可以实现此结果，具体取决于应用服务器环境，以及是否存在参与全局事务的任何其他具有 XA 能力的资源管理器。 可以利用 CICS TG for z/OS V6.1 的 XA 支持在任何数量的 CICS 区域和其他兼容 XA 的资源之间提供全局事务支持。可以在任何 WebSphere Application Server V6 配置中使用 CICS ECI XA 资源适配器。 可以利用 WebSphere Application Server for z/OS 中的 RRS 全局事务支持在任何数量的 CICS 区域和其他兼容 XA 或 RRS 的资源管理器之间提供全局事务支持。此功能基于 RRS，需要在同一 z/OS 系统上使用 CICS、CICS TG 和 WebSphere Application Server，并适用于 WebSphere Application Server for z/OS 和 CICS TG for z/OS 所有支持的版本。 如果在事务中没有调用具有 XA 能力的资源管理器（如 JDBC 数据源），那么可以在全局事务中使用 CICS ECI 资源适配器的本地事务支持。该方法是可行的，因为全局事务提供一个对两阶段提交协议的单阶段优化，在优化中，如果在事务中仅有一个资源管理器分支（也是就说，仅有单个资源），那么事务管理器使用单阶段提交流。有时，该方法被称为“唯一的代理优化”尽管该方法是主要的性能优化方法，但这意味着在不需要被准备的全局事务中可能支持单一的单阶段提交资源管理器（例如使用 CICS ECI 资源适配器的连接）。 WebSphere Application Server V6（和 WebSphere Application Server Enterprise V5）中提供的“最后的参与者支持”使单一具有单阶段提交能力的资源管理器（如来自 CICS ECI 资源适配器的连接）能够参与具有任何数量的两阶段提交能力的资源管理器的全局事务。 通过扩展的部署描述符 (XDD) 为给定的 EJB 组件启动 LPS 功能。WebSphere Application Server 中的企业应用程序设置提供了包含 Accept heuristic hazard 复选框的“最后的参与者支持”属性页（图 8）。 图 8. WebSphere Application Server：最后的参与者支持
也可以配置 WebSphere Application Server V6 事务服务程序，在提交单阶段提交资源以前写入额外的日志条目，以便在恢复期间确保合适的启发式报告。这可以通过管理控制台来启用，方法是导航到 Application Servers => Server => Server properties => Transaction Service，然后选中 Enable logging for heuristic reporting 复选框。 如果使用 z/OS 平台上的 WebSphere Application Server，事务支持有什么不同？ 在 WebSphere Application Server for z/OS 的本地模式中使用 CICS Transaction Gateway 时，CICS ECI 资源通过使用内部的 RRS 功能支持全局事务。此支持针对 z/OS 环境而优化，并且在使用远程网关时，不需要两阶段提交所需的 XA 事务流的开销。 此外，WebSphere Application Server for z/OS 允许在同一事务中使用带有任何具有 RRS 能力的资源的单一的具有单阶段提交能力的资源。与分布式平台上的 WebSphere Application Server 不同，不需要指定 LPS XDD 属性使用此行为。 请注意，由 CICS Transaction Gateway 为 WebSphere Application Server for z/OS 提供的 RRS 全局事务支持不支持使用 Bean 管理的本地事务。这意味着不支持使用 CICS ECI 连接工厂的 LocalTransaction 接口，详情请见问题 1。 在 z/OS 上部署 CICS TG 的好处是什么？ z/OS 上的 CICS TG 使用 EXCI 提供对 CICS 的高速交叉存储访问，这是其他平台无法提供的机制，因为它是基于 MRO 的通信机制。通过 EXCI 协议还可以使用 MVS Resource Recovery Services (RRS) 提供两阶段提交事务支持，这在 CICS TG V6.1 中可以通过 XA 支持获得。 CICS TG V6.1 for z/OS 还支持跨克隆的 CICS Transaction Gateway 守护进程之间的TCP/IP 负载平载，这样可以利用 TCP/IP 端口共享来提供较高的吞吐量和可用性。 如果在两阶段提交处理过程中出现网络连接故障，会发生什么情况？ 当事务处于处理状态时（在提交进程启动之前），如果指向 CICS Transaction Gateway 守护进程的 TCP/IP 网络连接中断，则在 CICS Transaction Gateway 守护进程接到中断的通知后会立即在 RRS 中将事务标记为回滚。不过，如果在提交进程中连接被中断，那么事务可能在未确定阶段被挂起，并且在连接重新建立后，守护进程将从事务管理器 (WebSphere Application Server) 等待提交或回退响应。 是否存在单阶段提交协议比两阶段提交协议更有好处的情况？ 尽管两阶段提交进程通常是分布式事务支持的先决条件，但是在某些实例中，使用单阶段提交进程就足够了，甚至会更好： 如果仅进行对 CICS 的单个调用，并且在事务中没有对可恢复资源的其他更新，就没必要使用全局事务。在这种情况下，可以使用带有 SYNCONRETURN 选项的非事务请求，使事务边界在进入 CICS 时开始，并在返回时终止。 如果全局事务中的所有请求都通过单个 CICS 系统进行，则 CICS ECI 资源适配器提供的单阶段提交本地事务支持可以提供充分的完整性，而不需要两阶段提交操作。此外，与 XA 事务相比，使用本地事务请求的性能更理想一些，由于在 WebSphere Application Server 中使用 RMLT 时，涉及的网络流量较少。不过，XA 协议在提交进程失败时可以提供再同步和恢复逻辑，在这一点上确实比此单阶段提交场景多提供一些附加的完整性。 如果在全局事务中使用具有本地事务能力的资源适配器（如 CICS ECI 资源适配器），则会发生什么故障？ 如果在全局事务中将具有本地事务能力的资源适配器和具有 XA 能力的资源管理器一起使用，那么在提交时 EJB 容器中将会发异常，因为两阶段提交进程不能使用单阶段提交资源管理器完成准备阶段。EJB 容器将报告一条消息，指出发生了非法尝试利用具有单阶段能力的资源和现有的具有两阶段能力的资源。 如果在 WebSphere Application Server 中使用 ECIRequest 类或 Common Connector Framework (CCF) 类，可以提供什么支持？ 在 WebSphere Application Server V5 中，仅在 Web 容器中支持 ECIRequest 类和 CCF 类，并且二者只能与非扩展逻辑工作单元一起使用。此外，它们还不能参与 WebSphere Application Server 提供的 JCA 托管环境，因此无法参与 RMLT 的范围或全局事务。这样，必须精心设计使用这些类的任何事务请求应用程序（并使用适当的补偿逻辑）才能确保结果的一致性。 如果 CICS 区域或事务意外故障，会发生什么情况？ XA 事务协议是一个假定的中止协议。这样，如果在事务处于处理状态时（即，在启动提交进程之前）发生任何故障，那么所有更新将回滚。这包括 CICS 子系统故障或网络中断。不过，对 CICS 异常终止的处理会略有不同。在 JCA 体系结构中，可以将任何故障（包括异常终止）作为 ResourceException 传播回调用 J2EE 组件。如果未捕获此异常，则缺省操作是提交事务（包括 CICS 执行的所有工作），直到异常终止点。如果您希望确保 CICS 事务异常终止触发自动回滚，则可以使用以下两种方法完成此任务： 在 CICS TS V2 和更高版本中，更改了 EXCI 选项表 DFHXCOPT，其中包括新的选项 ABENDBKOUT={NO|YES}。此选项可以指定 CICS 事务异常终止是否应触发恢复的 RRS 单元的自动回滚，并强制执行在 CICS 工作单元中所进行的所有更新的回退。此选项是在 CICS TS V3.1 中作为 APAR PK17426 以及在 CICS TS V2.2 和 V2.3 中作为 APAR PK17427 引入的（此 APAR 只应用于 EXCI，因此仅适用于 z/OS 上的 CICS TG。） 如果 J2EE 应用程序接收 ResourceException，则它可以检测该异常是否表示 CICS 事务异常终止，甚至可以确定特定的 CICS 异常终止代码是什么。检测到这种情况后，它就会在 EJB 会话上下文中将 EJB 的缺省操作标记为 setRollbackOnly，以强制事务管理器自动回滚事务。下面的代码示例说明了该方法：
结束语 我们回顾了 WebSphere Application Server 和 CICS 提供的事务支持，并阐述了如何使用 CICS ECI 资源适配器提供两个环境之间的事务协调。此集成的关键是资源适配器和 J2EE 应用服务器之间的 JCA 事务管理契约。此契约受各种因素的影响，包括 Web 或 EJB 容器的使用、EJB 事务属性、LTC 设置以及带有 WebSphere Application Server 的 XA 或 RRS 的使用。 (责任编辑：admin) |
