引言
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”事務屬性：
<container-transaction>
<method>
<ejb-name>CTGTesterCCI</ejb-name>
<method-intf>Remote</method-intf>
<method-name>execute</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
圖 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 以前的標准。
事務部署場景
在這一部分，我們將解釋把 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 選項進行鏈接。下面的代碼示例說明了該方法：
Context ic = new InitialContext();
cxfn = (ConnectionFactory) ic.lookup("java:comp/env/eis/ECICICS");
Connection cxn= cxnf.getConnection();
Interaction ixn= cxn.createInteraction();
ECIInteractionSpec ixnSpec= new ECIInteractionSpec(SYNC_SEND_RECEIVE,"CICSPROG");
JavaStringRecord jsr = new JavaStringRecord()
jsr.setText("DATA1");
ixn.execute(ixnSpec, jsr, jsr);
...
jsr.setText("DATA2");
ixn.execute(ixnSpec, jsr, jsr);
...
ixn.close();
cxn.close();
不過，與其在同一事務上下文下運行兩個對 CICS 的請求，還不如它們各自在 CICS 中作為獨立的工作單元運行，並使用單獨的 CICS 鏡像事務實例。這是因為在 Web 容器內部，在後續請求發出之前，每個交互都是自動提交的。
如果您需要兩個這樣的對 CICS 的請求在同一事務范圍內運行，那麼有兩種解決方案可以考慮。第一個建議的方法是使用 EJB 容器的事務控制（請參見問題 3），第二個方法是以編程方式創建並控制 Bean 管理的事務 (BMT) 的事務范圍。通過任何版本的 CICS Transaction Gateway 並使用連接工廠的本地事務支持可以完成此操作，如下面的代碼示例所示：
Context ic = new InitialContext();
cxfn = (ConnectionFactory) ic.lookup("java:comp/env/eis/ECICICS");
Connection cxn= cxnf.getConnection();
Interaction ixn= cxn.createInteraction();
ECIInteractionSpec ixnSpec= new ECIInteractionSpec(SYNC_SEND_RECEIVE,"CICSPROG");
JavaStringRecord jsr = new JavaStringRecord()
LocalTransaction tran = cxn.getLocalTransaction();
tran.begin();
jsr.setText("DATA1");
ixn.execute(ixnSpec, jsr, jsr);
...
jsr.setText("DATA2");
ixn.execute(ixnSpec, jsr, jsr);
...
tran.commit();
ixn.close();
cxn.close();
當控制這樣一組交互時，事務上下文對於 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 事務支持（如果需要）。
try {
Context ic = new InitialContext();
utx = (UserTransaction) ic.lookup("java:comp/UserTransaction");
cxfn = (ConnectionFactory) ic.lookup("java:comp/env/eis/ECICICS");
utx.begin();
Connection cxn= cxnf.getConnection();
Interaction ixn= cxn.createInteraction();
ECIInteractionSpec ixnSpec= new ECIInteractionSpec(SYNC_SEND_RECEIVE,"CICSPROG");
JavaStringRecord jsr = new JavaStringRecord()
jsr.setText("DATA1");
ixn.execute(ixnSpec, jsr, jsr);
...
jsr.setText("DATA2");
ixn.execute(ixnSpec, jsr, jsr);
utx.commit();
...
ixn.close();
cxn.close();
} catch (ResourceException re) {
try {
userTransaction.rollback();
}
如何鏈接到發出 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 調用類型
屬性 ECI 調用類型 CICS 鏡像任務事務范圍 NotSupported 非擴展 Synconreturn Required XA 事務 長時間運行 RequiresNew XA 事務 長時間運行 Supports 依賴於現在的上下文；Bean 方法可以在調用方的事務上下文下執行，並且 ECI 調用使用 XA 事務，如果該上下文不存在，則在未指定的事務上下文下執行。如果在未指定的事務上下文下執行，則 LTC 設置將控制最後得到的 ECI 調用類型。（請參閱本地事務容器。） Synconreturn 或長時間運行 Mandatory XA 事務或拋出異常；在調用方的事務上下文下執行 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，以強制事務管理器自動回滾事務。下面的代碼示例說明了該方法：
try {
eciInt.execute(eSpec, jsr, jsr);
} catch (ResourceException re) {
if (re instanceof com.ibm.connector2.cics.CICSTxnAbendException )
{
System.err.println("CICS ABEND detected."+ " Connection Factory="+targetCF.toString());
try {
mySessionCtx.setRollbackOnly();
} catch(IllegalStateException ise) {
ise.printStackTrace();
}
結束語
我們回顧了 WebSphere Application Server 和 CICS 提供的事務支持，並闡述了如何使用 CICS ECI 資源適配器提供兩個環境之間的事務協調。此集成的關鍵是資源適配器和 J2EE 應用服務器之間的 JCA 事務管理契約。此契約受各種因素的影響，包括 Web 或 EJB 容器的使用、EJB 事務屬性、LTC 設置以及帶有 WebSphere Application Server 的 XA 或 RRS 的使用。
