部署到 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 调用类型

　　Supports依赖于现在的上下文;Bean 方法可以在调用方的事务上下文下执行，并且 ECI 调用使用 XA 事务，如果该上下文不存在，则在未指定的事务上下文下执行。如果在未指定的事务上下文下执行，则 LTC 设置将控制最后得到的 ECI 调用类型。(请参阅本地事务容器。)Synconreturn 或长时间运行

　　MandatoryXA 事务或抛出异常;在调用方的事务上下文下执行 Bean 方法。如果调用程序没有提供上下文(换句话说没有全局活动)，则执行将失败并抛出异常。如果存在全局事务活动，则 ECI 调用类型将使用 XA 事务。长时间运行

　　Never非扩展Synconreturn

　　怎样发出对全局事务的 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 的使用。