利用J2EE Connector Architecture（9）

　　webSphere application Server V6(和 WebSphere Application Server Enterprise V5)中提供的“最后的参与者支持”使单一具有单阶段提交能力的资源管理器(如来自 CICS ECI 资源适配器的连接)能够参与具有任何数量的两阶段提交能力的资源管理器的全局事务。

　　通过扩展的部署描述符 (XDD) 为给定的 EJB 组件启动 LPS 功能。WebSphere Application Server 中的企业应用程序设置提供了包含 Accept heuristic hazard 复选框的“最后的参与者支持”属性页(图 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 的范围或全局事务。这样，必须精心设计使用这些类的任何事务请求应用程序(并使用适当的补偿逻辑)才能确保结果的一致性。