<b>操作 J2EE Connector Architecture</b>[Java编程]
本文“<b>操作 J2EE Connector Architecture</b>[Java编程]”是由七道奇为您精心收集，来源于网络转载，文章版权归文章作者所有，本站不对其观点以及内容做任何评价，请读者自行判断，以下是其具体内容：
引言
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 的最后的参与者支持功效扩大了全局事件模子,可以支持一个单阶段提交资源参与具有任何数目的两阶段提交本领的资源的全局事件.在事件提交时,利用程序服务器 style="COLOR: #000000" href="http://server.it168.com/" target=_blank>服务器首先预备两阶段提交资源管理器,假如成功,则调用单阶段提交资源举行提交.然后,两阶段提交资源大概提交大概回滚,具体取决于来自单阶段提交资源的呼应.此历程有效地指派了对单阶段提交资源的事件合作.
图 3. 最后的参与者支持
与两阶段提交进程差别,单阶段提交资源在通信失利时无法恢复.因此,在提交单阶段提交资源时通信失利会带来混合的事件后果风险(启迪式危险).两阶段提交资源可以回滚,但单阶段提交资源的后果是未知的,它大概已提交大概已回滚.因此,必须将利用程序配置为承受此类启迪式后果的额外风险,下文对此举行了具体阐明.
在特定的情形中,比方假如利用系统间分布式程序衔接 (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 需求考虑利用支持本地事件的资源管理器.
事件属性在 EJB 布置描写符(ejb-jar.xml 文件)中设置,事件属性是掌握属性,在掌握情形下当调用 Bean 办法时启动全局事件.此事件属性显示在"container-transaction"部份,并利用"trans-attribute"标志指定.比方,以下 XML 定义 CTGTesterCCI Bean 上的远程 execute() 办法具有"Required"事件属性:
| 1 <container-transaction> 2 <method> 3 <ejb-name>CTGTesterCCI</ejb-name> 4 <method-intf>Remote</method-intf> 5 <method-name>execute</method-name> 6 </method> 7 <trans-attribute>Required</trans-attribute> 8 </container-transaction> 9 |
图 7 显示了若何利用 IBM Rational® Application Developer 中的 EJB 布置描写符编辑器定义这些设置的情形.
图 7. Rational Application Developer 中的事件属性
事件属性的大概值及其描写在表 1 中列出:
表 1. EJB 事件属性 事件属性描写
| 事件属性 | 描写 |
| NotSupported | Bean 办法不在事件的上下文中履行. |
| Required | Bean 办法将在事件的上下文中履行. |
| RequiresNew | Bean 办法将在新事件的上下文中履行. |
| Supports | Bean 办法可以在事件上下文中履行,也可以不在事件上下文中履行. |
| Mandatory | Bean 办法必须在 EJB 客户机的事件上下文中履行. |
| Never | Bean 不会在事件上下文中调用. |
本地事件容器
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 从前的尺度.
在 Web 容器中布置的 Servlet 组件贫乏 EJB 组件的大大都事件属性.固然如此,Web 容器还是支持 RMLT 和 LTC 容器战略,利用这两个战略可以影响 ECI 资源适配器发出的 JCA 恳求.
在同一事件范围内,Servlet 可否发出多个 ECI 恳求?
假如在一个交互中两次调用 execute() 办法,这样会调用两个呼应的到 CICS 的 ECI 调用,二者都利用 CICS SYNCONRETURN 选项举行链接.下面的代码示例阐明了该办法:
| 1 Context ic = new InitialContext(); 2 cxfn = (ConnectionFactory) ic.lookup("java:comp/env/eis/ECICICS"); 3 Connection cxn= cxnf.getConnection(); 4 Interaction ixn= cxn.createInteraction(); 5 ECIInteractionSpec ixnSpec= new ECIInteractionSpec(SYNC_SEND_RECEIVE,"CICSPROG"); 6 JavaStringRecord jsr = new JavaStringRecord() 7 8 jsr.setText("DATA1"); 9 ixn.execute(ixnSpec, jsr, jsr); 10 ... 11 jsr.setText("DATA2"); 12 ixn.execute(ixnSpec, jsr, jsr); 13 ... 14 ixn.close(); 15 cxn.close(); 16 |
不过,与其在同一事件上下文下运行两个对 CICS 的恳求,还不如它们各安闲 CICS 中作为独立的工作单元运行,并利用单独的 CICS 镜像事件实例.这是因为在 Web 容器内部,在后续恳求发出之前,每个交互都是自动提交的.
假如您需求两个这样的对 CICS 的恳求在同一事件范围内运行,那么有两种办理筹划可以考虑.第一个倡议的办法是利用 EJB 容器的事件掌握(请拜见问题 3),第二个办法是以编程方法成立并掌握 Bean 管理的事件 (BMT) 的事件范围.通过任何版本的 CICS Transaction Gateway 并利用衔接工厂的本地事件支持可以完成此操作,以下面的代码示例所示:
| 1 Context ic = new InitialContext(); 2 cxfn = (ConnectionFactory) ic.lookup("java:comp/env/eis/ECICICS"); 3 Connection cxn= cxnf.getConnection(); 4 Interaction ixn= cxn.createInteraction(); 5 ECIInteractionSpec ixnSpec= new ECIInteractionSpec(SYNC_SEND_RECEIVE,"CICSPROG"); 6 JavaStringRecord jsr = new JavaStringRecord() 7 8 LocalTransaction tran = cxn.getLocalTransaction(); 9 tran.begin(); 10 11 jsr.setText("DATA1"); 12 ixn.execute(ixnSpec, jsr, jsr); 13 ... 14 jsr.setText("DATA2"); 15 ixn.execute(ixnSpec, jsr, jsr); 16 ... 17 tran.commit(); 18 ixn.close(); 19 cxn.close(); 20 |
当掌握这样一组交互时,事件上下文关于 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 事件支持(假如需求).
| 1 try { 2 3 Context ic = new InitialContext(); 4 utx = (UserTransaction) ic.lookup("java:comp/UserTransaction"); 5 cxfn = (ConnectionFactory) ic.lookup("java:comp/env/eis/ECICICS"); 6 7 utx.begin(); 8 9 Connection cxn= cxnf.getConnection(); 10 Interaction ixn= cxn.createInteraction(); 11 ECIInteractionSpec ixnSpec= new ECIInteractionSpec(SYNC_SEND_RECEIVE,"CICSPROG"); 12 JavaStringRecord jsr = new JavaStringRecord() 13 14 jsr.setText("DATA1"); 15 ixn.execute(ixnSpec, jsr, jsr); 16 ... 17 jsr.setText("DATA2"); 18 ixn.execute(ixnSpec, jsr, jsr); 19 20 utx.commit(); 21 ... 22 ixn.close(); 23 cxn.close(); 24 } catch (ResourceException re) { 25 try { 26 userTransaction.rollback(); 27 } 28 |
若何链接到发出 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 中的事件完好性.
也可以配置 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 的高速穿插存储 style="COLOR: #000000" href="http://storage.it168.com/" target=_blank>存储拜候,这是其他平台无法供应的机制,因为它是基于 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,以强迫事件管理器自动回滚事件.下面的代码示例阐明了该办法:
| 1 try { 2 eciInt.execute(eSpec, jsr, jsr); 3 } catch (ResourceException re) { 4 5 if (re instanceof com.ibm.connector2.cics.CICSTxnAbendException ) 6 { 7 System.err.println("CICS ABEND detected."+ " Connection Factory="+targetCF.toString()); 8 try { 9 mySessionCtx.setRollbackOnly(); 10 } catch(IllegalStateException ise) { 11 ise.printStackTrace(); 12 } 13 |
完毕语
我们回想了 WebSphere Application Server 和 CICS 供应的事件支持,并阐述了若何利用 CICS ECI 资源适配器供应两个环境之间的事件调和.此集成的关键是资源适配器和 J2EE 利用服务器之间的 JCA 事件管理契约.此契约受各种因素的影响,包含 Web 或 EJB 容器的利用、EJB 事件属性、LTC 设置以及带有 WebSphere Application Server 的 XA 或 RRS 的利用.
以上是“<b>操作 J2EE Connector Architecture</b>[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：
| 本文地址： | 与您的QQ/BBS好友分享! |
- 好的评价 如果您觉得此文章好，就请您
0%(0) 
- 差的评价 如果您觉得此文章差，就请您
0%(0) 
中查找“<b>操作 J2EE Connector Architecture</b>”更多相关内容
中查找“<b>操作 J2EE Connector Architecture</b>”更多相关内容