루크의 기록 : J2EE Connector Architecture 활용하기

2007년 01월 03일

J2EE Connector Architecture 활용하기

IBM WebSphere Developer Technical Journal: J2EE Connector Architecture 활용하기 (한글)

Phil Wakelin, CICS Transaction Gateway Technical Planner, IBM
Peter Masters, CICS Development, IBM

CICS 애플리케이션과 J2EE 컴포넌트의 통합은 많은 기업들이 직면하고 있는 문제입니다. 이 글에서는, IBMWebSphere Application Server에 전개된 CICS 애플리케이션과 J2EE 컴포넌트의 트랜잭션 통합에 J2EE Connector Architecture (JCA)와 CICS Transaction Gateway가 어떻게 사용되는지를 설명합니다. WebSphere Application Server V6.x에 맞춰 업데이트 되었습니다.

머리말

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의 two-phase commit 지원인 새로운 XA도 설명하겠다. WebSphere Application Server내의 서블릿과 EJB 컴포넌트에 사용할 수 있는 트랜잭션 컨트롤을 상세히 분석하고, 이러한 컨트롤을 사용하여 WebSphere Application Server와 CICS에 전개된 애플리케이션들 간 다양한 트랜잭션 통합 레벨을 설명하도록 하겠다.

이 글은 JCA와 CICS를 사용하는 트랜잭션 의미를 이해하고자 하는 애플리케이션 디자이너와 아키텍트를 위한 글이다. CICS와 JCA에 대한 기본적인 지식이 있는 것으로 간주한다.

분할의 역사

분할이라는 개념은 SQL Server에서는 새로운 것이 아닙니다. 사실 SQL Server 제품의 모든 릴리스에서 여러 가지 형태의 분할이 가능했습니다. 그러나 분할 스키마를 만들고 유지 관리하기 위해 특수하게 디자인된 기능이 없었기 때문에 분할은 번거로웠으며 활용도가 낮았습니다. 또한 사용자 및 개발자는 보다 복잡한 데이터베이스 디자인으로 인해 스키마를 잘못 이해했기 때문에 이점이 줄어들었습니다. 그러나 이 개념은 기본적으로 상당한 성능상의 이점을 제공하므로 SQL Server 7.0에서는 분할된 뷰를 통해 분할의 형태를 사용 가능하도록 함으로써 이 기능을 향상시켰습니다. 그리고 이제 SQL Server 2005는 분할된 테이블을 통해 대형 데이터 집합을 분할하기 위한 매우 뛰어난 고급 기능을 제공합니다.

트랜잭션: 이것은 무엇인가?

J2EE 세계에서, 트랜잭션은 하나의 작업 단위로서, 이 안에서 복구 가능한 리소스들에 대해 여러 업데이트가 자동으로 이루어진다. CICS 세계에서, 트랜잭션은 특정 트랜잭션 식별자에 의해 호출된 CICS 프로그램(또는 프로그램의 시퀀스)에 의해 수행된 작업을 의미하며, 특정 CICS 태스크 범위에서 실행된다. 이 CICS 태스크는 동기화 포인트(syncpoints)에 의해 구분된 복구 가능한 작업 단위(또는 논리적 작업 단위)들로 구성될 수 있다. 이러한 작업- 단위 는 복구 가능한 가장 작은 원자 단위이고, 이 같은 것은 J2EE 세계의 트랜잭션과 비슷하다.

필수 컴포넌트

트랜잭션 환경 내에서, 모든 참여자들은 리소스 매니저나 트랜잭션 매니저로 구분된다. 리소스 매니저는 파일이나 큐 같은 복구 가능한 데이터를 관리한다. 트랜잭션 매니저는 트랜잭션에 반응하고 여러 리소스 매니저들간 트랜잭션 결과를 조정한다. 이들 사이에서, 트랜잭션 매니저와 리소스 매니저들은 복구 가능한 리소스들의 업데이트를 신뢰성 있게 조정한다. 원자성, 일관성, 고립, 내구성 같은 트랜잭션 규칙들이 관리된다. 이를 위해서, 각 참여자는 공통의 아키텍처 표준을 구현해야 한다. 다음 섹션에서는 다음의 표준과 프로토콜을 살펴보도록 하겠다.

ㆍJ2EE Connector Architecture (JCA)
ㆍTwo-phase commit.

JCA는 J2EE 표준의 일부이고 리소스 어댑터에 의해 구현되는 시스템 콘트랙트를 정의한다. 이러한 시스템 콘트랙트는 리소스 어댑터가 트랜잭션 관리, 연결 관리, 보안에 제공하는 서비스 품질을 정의한다. (그림 1).

그림 1. JCA 시스템 콘트랙트

J2EE 아키텍처에서, 분산 트랜잭션은 글로벌 트랜잭션이라고 불리고, 복구 가능한 리소스를 관리하는 시스템은 리소스 매니저로 알려져 있다. (예, CICS, IMS™, DB2??). 이러한 리소스 매니저들은 트랜잭션에 대한 지원에 기반하여 분류된다. two-phase coordination (XAResource 인터페이스 제공)을 지원하거나, (LocalTransaction 인터페이스를 통해서) one-phase coordination만 지원하거나, 또는 비 트랜잭션(non-transactional)일 수 있다.

트랜잭션 관리의 경우, 리소스 어댑터의 전개 디스크립터(ra.xml 파일)리소스 어댑터는 다음과 같은 콘트랙트 중 하나를 구현해야 한다.

ㆍXA Transaction -- two-phase commit 프로세스에 완전히 참여할 수 있는 리소스 어댑터이고, 글로벌 트랜잭션의 결과에 영향을 줄 수 있다.

ㆍLocalTransaction -- 리소스 매니저에 국한된(이 경우, CICS region) 트랜잭션에 참여할 수 있는 리소스 어댑터이지만, two-phase commit 트랜잭션 기능은 없다. 정갈한 문서를 유지하기 위해서, 리소스 매니저 로컬 트랜잭션(RMLT)를 싱글 리소스 매니저에 국한된 트랜잭션을 의미하는 용어로 사용한다.

ㆍNoTransaction -- 어떤 트랜잭션 속성도 없는 리소스 어댑터. 트랜잭션 콘텍스트에 참여할 수는 있지만 트랜잭션의 결과에 (영향을 주지도 않고) 영향을 받지도 않는다.

WebSphere Application Server 트랜잭션 지원은 한 트랜잭션 내에서 Two-phase 기능을 하는(XA Transaction) 리소스 매니저를 조정한다. 또한, 싱글 one-phase 기능의 (Local transaction) 리소스 매니저가 다른 리소스 매니저의 부재 시 트랜잭션 내에서 사용될 수 있도록 한다.

Two-phase commit

분산 트랜잭션 프로세싱의 필수적인 부분은 two-phase commit 프로세스이다. 이는 트랜잭션에 있는 모든 리소스 매니저들이 어떤 오류에도 관계 없이 신뢰성 있게 조정될 수 있도록 보장하는 흐름 구조이다. two-phase commit는 모든 트랜잭션 프로토콜에 의해 구현되고, 근본 개념은 기본적으로 같다. 다음 디스크립션은 XA 스팩에 따라 흐름을 요약한 것이다. CICS나 LU6.2 같은 기타 프로토콜들은 흐름에 대해 다른 용어와 변수를 사용한다. (CICS syncpoint 흐름은 CICS Intercommunication Guide, SC34-6243, Chapter 2: Recovery and restart in interconnected systems를 참조하라.)

two-phase commit 프로세스 전에, 트랜잭션 동안 수행된 모든 작업은 실행 중인 것으로 간주되고, 이 기간 동안 실패한 것은 롤백으로 이어진다. 업데이트는 트랜잭션 매니저가 two-phase commit 프로세스를 초기화 할 때에만 가능하다.

그림 2. Two-phase commit

two-phase commit 프로세스의 첫 번째 단계(Stage 1)는 다음과 같다.:

a.트랜잭션 매니저는 모든 리소스 매니2저들에게 복구 가능한 리소스들을 위임을 준비할 것을 요청한다.

b.각 리소스 매니저는 (준비될 경우) 긍정적으로 응답하거나 부정적으로 응답한다.(롤백) 리소스 매니저가 긍정적으로 응답한다면 필요한 정보를 안정적으로 기록하고, 응답을 준비하고, 다음 스테이지에서 결정된 것 처럼 트랜잭션의 최종 결과를 따른다.

c.리소스 매니저는 불확실한 것으로 기술된다. 트랜잭션 매니저에 대한 트랜잭션의 최종 결과를 삭제했고, 이제는 트랜잭션의 실제 결과에 대해서도 의심하기 때문이다.

두 번째 단계에서(Stage 2), 모든 리소스 매니저들이 긍정적으로 응답된 것으로 간주한다.:

a.트랜잭션 매니저는 각 리소스 매니저에게 커미트 흐름과 함께 응답한다. 하지만, 리소스 매니저가 응답에 실패하면, 트랜잭션 매니저는 트랜잭션이 중지된 것으로 간주하기 전에 준비 흐름을 다시 보낸다.

b.커미트 흐름을 받을 때, 리소스 매니저는 복구 가능한 리소스에 대한 업데이트를 마감하고, 리소스에 대한 모든 잠금을 해제하거나 파일을 연다.

c.리소스 매니저는 최종 커미트 된 흐름으로 응답하고, 이는 더 이상 의심 상태가 아닌 트랜잭션 매니저를 가리킨다.

d.최종 커미트 흐름을 트랜잭션 매니저에서 받지 못하면, 트랜잭션 매니저는 이 커미트가 리소스 매니저에 아직 도착하지 않은 것으로 간주하고, 긍정적인 응답을 받을 때까지 커미트를 다시 보내야 한다.

커미트 프로세싱 동안 트랜잭션 매니저가 실패하면, 트랜잭션은 리소스 매니저에서 의심 상태로 남겨진다. 재시작 시, 트랜잭션 매니저는 리소스 매니저와 다시 연결되어 트랜잭션 상태를 발견하고, 커미트 또는 트랜잭션 취소 등으로 커미트 프로세싱을 계속 진행한다.

Last participant 지원

J2EE 트랜잭션 환경에서, WebSphere Application Server의 Last participant 지원 기능은 글로벌 트랜잭션 모델을 확장하여 하나의 one-phase commit 리소스를 two-phase commit 가능 리소스를 가진 글로벌 트랜잭션에 참여시킨다. 트랜잭션 커미트에서, 애플리케이션 서버는 two-phase commit 리소스 매니저를 준비하고, 이것이 성공하면 one-phase commit 리소스는 실행을 요청 받는다. two-phase commit 리소스는 one-phase commit 리소스의 응답에 따라서 실행 되거나 롤백된다. 이 프로세스는 트랜잭션 조정을 효과적으로 one-phase commit 리소스에 성공적으로 위임한다.

그림 3. Last participant 지원

Last participant 지원은 WebSphere Application Server Enterprise V5의 일부로 제공되고, WebSphere Application Server V6과 이후 버전의 기본 기능으로 사용할 수 있다.

two-phase commit 프로세스와는 다르게, one-phase commit 리소스와 관련된 통신 오류로부터 복구된 것은 없다. 따라서, one-phase commit 리소스의 실행 동안 통신 오류는 혼합된 결과의 위험성을 트랜잭션에 초래한다. (heuristic hazard) two-phase commit 리소스는 롤백 되지만, one-phase commit 리소스의 결과는 알려지지 않는다. 실행되거나 롤백된다. 따라서 애플리케이션들은 그와 같은 예정된 결과의 위험성까지 포용하도록 설정되어야 한다. 상세한 내용은 이 글 후반에 설명하겠다.

CICS 작업 단위: 트랜잭션, 태스크, syncpoint

앞서 언급했던 것처럼, “트랜잭션”이라는 용어는 많은 뜻을 내포하고 있다. 이 글에서는, CICS 트랜잭션을 CICS 영역에서 초기화 된 작업을 의미하고, 네 개의 문자로 된 트랜잭션 ID(tranid)하에서 실행된다. 이러한 tranid는 로딩 될 초기 프로그램의 이름을 짓는 CICS 리소스 정의와, 관련 태스크들이 실행 될 CICS 트랜잭션의 속성이다. 역사적으로, 이들은 Program Control Table (PCT)를 구현했던 매크로에 의해서 정의되었지만 요즘은 resource definition online (RDO) 데이터베이스 내에서 TRANSACTION 정의에 의해 정의된다. 트랜잭션 초기화 때, CICS는 새로운 태스크를 시작한다. 이는 수행 될 트랜잭션 작업의 초기 바운더리이다. 복구 가능한 리소스로의 모든 업데이트나 다른 트랜잭션 시스템에 대한 요청들은, 동기화 포인트(syncpoint)가 CICS 프로그램 내에 도달할 때까지, 이 작업 단위의 새로운 일부가 된다. syncpoint는 EXEC CICS SYNCPOINT 명령어를 사용하여 CICS 애플리케이션 내에서 분명하게 코딩 되거나, 태스크가 종료할 때 도달하게 된다. 이 syncpoint에서, 트랜잭션 매니저로서 CICS는 모든 관련 리소스 매니저들을 준비하고 성공적인 커미트로서 결과를 조정하거나, 이것이 불가능 하면, 모든 복구 가능한 업데이트가 작업 단위의 시작 이전의 상태로 롤백된다. (그림 4).

그림 4. CICS 트랜잭션

시스템 간 분산 프로그램 링크(DPL) 요청이 사용되는 특정 환경에서, 연결된 CICS 트랜잭션은 원격 CICS 시스템에 의해서 조정될 수 있다. CICS TG는 외부 호출 인터페이스를 사용하여 이러한 상황을 확장시켜서 CICS 작업 단위를 초기화 하고 조정한다. CICS TG 용어에서, 이는 확장된 논리적 작업 단위라고 일컬어 진다. (그림 5) DPL 요청이 CICS 프로그램을 호출할 때 사용되면, CICS 프로그램은 syncpoint 명령어를 실행하는 것이 더 이상 허용되지 않는다. 트랜잭션은 원격 시스템에 의해 조정되기 때문이다.

그림 5. 확장된 작업 단위

또한, 이 반대의 상황도 가능하다. 호출된 CICS 트랜잭션이 애플리케이션을 호출하는 개별 트랜잭션 콘텍스트에서 실행되는 상황이다. 이를 sync-on-return이라고 하고, 이는 CICS의 미러(mirror) 트랜잭션을 제어하면 호출 애플리케이션에 컨트롤을 리턴할 때 syncpoint를 실행한다는 것을 의미한다. (그림 6) sync-on-return 유형 링크를 사용하면 호출된 CICS 프로그램이 EXEC CICS SYNCPOINT 명령어를 실행할 수 있도록 한다. 또 다른 트랜잭션 매니저에 종속되지 않기 때문이다.

그림 6. sync-on-return 링크

CICS Transaction Gateway의 트랜잭션 지원

CICS Transaction Gateway를 사용하여 J2EE 애플리케이션에서 CICS로 트랜잭션 통합을 할 때, 기반 연결은 ECI가 제공한다. 이것은 호출 애플리케이션(J2EE 서블릿이나 EJB 컴포넌트)이 호출된 CICS 트랜잭션을 조정하도록 한다. 하지만, 제공된 기능을 이해하기 위해서는, two-phase commit 네트워크 연결의 필수 트랜잭션 컴포넌트와 복구 가능한 로깅과 관련하여 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 흐름에 two-phase commit 트랜잭션 코디네이션을 제공하는 유일한 프로토콜은 External CICS Interface (EXCI)이다. 이는 CICS TS for z/OS for batch MVS™ 애플리케이션에서 제공하는 인터페이스이고, MVS Resource Recovery Services (RRS)와 관련하여 트랜잭션을 지원한다. 이 지원을 Transactional EXCI라고 하고, MVS 배치(batch) 애플리케이션(이 경우, CICS Transaction Gateway)과 목표 CICS 영역들이 같은 MVS 이미지에 있어야 한다.

CICS TG V6.1의 XA 지원은 트랜잭션 EXCI 지원을 기반으로 구현된다. 새로운 CICS ECI XA 리소스 어댑터를 통해 CICS로의 요청에 글로벌 트랜잭션을 지원한다. 이는 WebSphere Application Server(z/OS)에서 실행되는 로컬 J2EE 애플리케이션이나 AIX 같은 분산 플랫폼에서 WebSphere Application Server에서 실행되는 원격 J2EE 애플리케이션에 대해 two-phase commit 글로벌 트랜잭션을 지원한다.

하지만, CICS TG가 분산 플랫폼에서 실행될 때, one-phase commit 연결이 여전히 사용되어야 하고, 따라서 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 트랜잭션 지원을 구현하고, 글로벌 two-phase commit 트랜잭션을 완전히 지원한다. JCA 1.5 버전에서만 사용할 수 있고, CICS TG for z/OS와 CICS TS for z/OS와 연결하여 WebSphere Application Server V6 내에서 사용할 수 있도록 CICS Transaction Gateway v6.1 for z/OS에서만 제공된다.

ㆍCICS EPI 리소스 어댑터 -- 3270 터미널 기반 프로그램으로의 액세스에 사용될 수 있다. CICS 3270 인터페이스의 특성 상 어떤 글로벌 트랜잭션 지원도 되지 않으며, CICS 애플리케이션의 트랜잭션 통합에는 사용될 수 없다. JCA 1.0과 1.5 버전이 제공되지만, 멀티 플랫폼 상에서 CICS Transaction Gateway와 함께 사용될 수 있다.

WebSphere Application Server on z/OS의 RRS 트랜잭션 지원

WebSphere Application Server for z/OS를 사용할 때, CICS ECI 리소스 어댑터는 추가 RRS 트랜잭션 모드를 사용하여 글로벌 트랜잭션을 지원한다. 이 RRS 트랜잭션 모드는 논리적 게이트웨이가 사용될 때 자동적으로 사용된다. 로컬 게이트웨이의 사용은 CICS ECI 연결 팩토리 ConnectionURL 매개변수에 “local”을 설정하는 것으로 표시되고, 리소스 어댑터는 WebSphere Application Server JVM 내의 CICS Transaction Gateway EXCI 인터페이스를 직접 호출하여 독립 게이트웨이의 필요성을 없애야 함을 나타낸다. 이러한 공존 방식은 줄어든 경로 길이(pathlength)와 MVS Resource Recovery Services (RRS)로의 two-phase commit 프로세싱 이라는 두 가지 퍼포먼스 혜택을 제공한다.

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 컨테이너, 클라이언트 컨테이너, 애플릿 컨테이너가 있다. WebSphere Application Server V5와 V6에서, JCA 지원은 웹과 EJB 컨테이너 내에서 제공되고, 두 개 모두 JCA 커넥션 풀링 메커니즘과 J2EE 컴포넌트에서 트랜잭션 콘텍스트의 제공을 지원한다.

Web 컨테이너

웹 컨테이너의 기본 기능은 서블릿과 JSP 컴포넌트를 위한 것이지만, 글로벌 트랜잭션 지원도 한다. 하지만, 애플리케이션이 프로그램 방식으로 트랜잭션 범위를 제어하더라도, 웹 컨테이너에서 제공되는 컨테이너 관리 트랜잭션 서비스가 없다. 리소스 매니저 로컬 트랜잭션은 ConnectionFactory에서 획득한 Connection 객체에 대해 getLocalTransaction() 메소드를 호출함으로써 제어될 수 있다. 이는 JCA 커넥션 팩토리(CICS 영역)의 싱글 인스턴스에 국한된 one-phase commit 트랜잭션 콘텍스트를 제공한다. two-phase commit 트랜잭션 콘텍스트는 javax.transaction.UserTransaction 인터페이스를 사용하여 만들어져서, 트랜잭션을 시작 및 종료한다. 이 같은 애플리케이션은 HTTP 요청 수명 내에서 트랜잭션을 실행해야 한다. 하나의 서블릿으로 여러 HTTP 요청을 통해 트랜잭션의 라이프사이클을 확장하는 것은 불가능 하고, 서블릿 service() 메소드의 끝에서 종료되지 않은 글로벌 트랜잭션은 WebSphere Application Server에 의해 롤백된다.

EJB 컨테이너

EJB 컨테이너는 컨테이너 관리 트랜잭션(CMT)와 빈 관리 트랜잭션(BMT)를 포함하여, 글로벌 트랜잭션에 대한 전체 트랜잭션 지원을 제공한다. 세션 빈과 메시지 중심 빈은 두 유형 중 한 유형을 채택한다. 엔터티 빈은 CMT로만 제한된다. BMT를 사용하는 빈들은 트랜잭션 한계 설정에 책임이 있고 UserTransaction 인터페이스를 사용하여 트랜잭션을 시작 및 종료한다. CMT는 트랜잭션 제어를 애플리케이션 서버에 위임하여, 애플리케이션 개발자가 비즈니스 로직을 개발하는데 집중하면서, 애플리케이션의 트랜잭션 속성들이 전개 시 결정될 수 있도록 하기 때문에 선호된다. CMT를 이용한 트랜잭션 제어의 핵심은 EJB 트랜잭션 애트리뷰트이다. 다음에 설명하도록 하겠다.

트랜잭션 애트리뷰트

트랜잭션 애트리뷰트는 EJB 전개 디스크립터(ejb-jar.xml 파일)에서 설정되고 빈 메소드가 호출될 때 글로벌 트랜잭션이 시작되는 환경 하에서 제어하는 애트리뷰트이다. 이 트랜잭션 애트리뷰트는 <container-transaction> 섹션에 나타나고, <trans-attribute> 태그로 설정된다. 예를 들어, 다음 XML은 CTGTesterCCI 빈에 대한 원격 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>

IBM Rational?? Application Developer의 EJB Deployment Descriptor 에디터를 사용하여 이 설정을 정의하는 모습은 그림 7에 나타나 있다.

그림 7. Rational Application Developer의 트랜잭션 애트리뷰트

트랜잭션 애트리뷰트의 값과 설명은 표 1에 정리했다.:

표 1. EJB 트랜잭션 애트리뷰트

로컬 트랜잭션 제한

EJB 2.0 스팩은 글로벌 트랜잭션 없이 메소드가 실행되는 경우에, 컨테이너의 작동을 지정하지 않는다. 이는 서블릿, 빈 관리 트랜잭션을 사용하는 세션 빈, 기타 시나리오에도 마찬가지다. 이 경우, 애플리케이션은 “지정되지 않은 트랜잭션” 콘텍스트에서 실행되도록 명령을 받는다. 일관성과 이식성을 이룩하기 위해, WebSphere Application Server는 로컬 트랜잭션 제한(local transaction containment LTC) 정책을 사용하여 “지정되지 않은 트랜잭션” 콘텍스트를 구현한다. 이 LTC 정책은 웹 컨테이너와 EJB 컨테이너에 의해 사용되는 효과적인 범위 설정 장치로서 글로벌 트랜잭션 밖에서 파견된 작업의 시작과 끝을 정한다. 이 같은 LTC 내에서 리소스 매니저(CICS)로의 액세스는 LTC의 끝에서 결정되어야 하는 리소스 매니저 로컬 트랜잭션(RMLT)을 통해서 이루어진다. LTC 범위와 프로그래밍 방식의 인터랙션 방식은 없다. 대신, LTC 범위 지정이 J2EE 애플리케이션에 영향을 주는 방식은 전개 시 J2EE 컴포넌트에 설정될 수 있는 세 개의 확장 전개 디스크립터(XDD)에 의해서 제어된다.:

ㆍBoundary -- BeanMethod (default) 또는 ActivitySession값을 가질 수 있다. ActivitySession은 WebSphere Application Server Enterprise V5에서만 사용할 수 있는 EJB 컨테이너의 확장이다. 로컬 트랜잭션 기반 리소스 매니저의 메소드 한계를 넘어 확장된 작업 단위를 제공한다. (Transactional services in WebSphere Application Server Enterprise V5, REDP3759 참조.)

ㆍResolver -- ContainerAtBoundary 또는 Application (default) 값을 갖는다. 글로벌 트랜잭션 콘텍스트(Never의 트랜잭션 애트리뷰트) 밖에 있는 EJB 컨테이너에서 ECI 요청이 발생되면, 리졸버 애트리뷰트가 Application으로 설정될 경우, ECI 호출 유형은 비확장이 될 것이다. 반대로, 리졸버 애트리뷰트가 ContainerAtBoundary로 설정되면, 리소스 매니저 로컬 트랜잭션이 시작되고, ECI 호출 유형은 확장형이 되고 EJB 메소드 범위에서 컨테이너에 의해 해결된다.

ㆍUnresolvedAction -- Commit 또는 Rollback (default) 값을 가질 수 있다. EJB 컨테이너나 웹 컨테이너를 위해 설정될 수 있고, 컨테이너가 LTC 바운더리에서 두드러지는 RMLT와의 연결을 제거하는 방법을 알려준다. 이는 웹 컴포넌트(서블릿)에 유일하게 설정 가능한 LTC 설정이고, LocalTransaction.begin() 메소드를 사용하여 빈 관리 트랜잭션에 적용한다. 모든 컨테이너 관리 트랜잭션은 트랜잭션이 완료한 후에 자동 실행되기 때문에, 이 애트리뷰트는 웹 컨테이너의 컨테이너 관리 트랜잭션에 의해 사용되지 않는다.

다음은 LTC 정책을 사용할 때 유의할 점이다.:

ㆍLTC 범위는 각 J2EE 컴포넌트에 국한된다. 따라서, EJB 컴포넌트 A는 LTC A 하에서 실행되고 EJB 컴포넌트 B를 호출한다면, 컴포넌트 B는 개별 LTC 하에서 실행되어야 한다.
ㆍ애플리케이션이 글로벌 트랜잭션 밖에서 실행된다면, 웹 컴포넌트나 BMT 엔터프라이즈 빈이 J2EE 1.3 이전 레벨이 아닌 이상, 컨테이너는 언제나 LTC 범위를 지정해야 한다.

트랜잭션 전개 시나리오

이 섹션에서는, 서블릿과 EJB 컴포넌트를 WebSphere Application Server 환경에 전개하는 방법과, 트랜잭션 제어를 효과적으로 사용하는 방법을 설명하겠다. 웹 컨테이너와 EJB 컨테이너 환경과 관련하여 자주 묻는 질문들을 선별했고, 이에 대한 실질적인 솔루션을 설명한다.

1. 같은 트랜잭션 범위 내에서, 서블릿에서 여러 ECI 요청들을 어떻게 만드는가?
2. SYNCPOINT 명령어를 실행하는 CICS 프로그램에 연결하는 방법은?
3. 같은 트랜잭션 범위 내에서, EJB 컴포넌트에서 다중 ECI 요청이 가능한가?
4. 글로벌 트랜잭션의 CICS 부분에 ECI 요청을 하는 방법은?
5. z/OS에서 WebSphere Application Server를 사용한다면, 트랜잭션 지원이 달라지는가?
6. z/OS에 CICS TG를 전개하면 어떤 점이 좋은가?
7. two-phase commit 프로세싱 중에 네트워크 연결이 실패한다면 어떤 일이 발생하는가?
8. one-phase commit 프로토콜이 two-phase commit 프로토콜 보다 더 이로운 상황이 있는가?
9. 로컬 트랜잭션 리소스 어댑터(CICS ECI 리소스 어댑터)가 글로벌 트랜잭션에 추가된다면 어떤 문제가 발생하는가?
10. ECIRequest 클래스 또는 Common Connector Framework (CCF) 클래스를 WebSphere Application Server에서 사용한다면 어떤 지원을 받을 수 있는가?
11. CICS 영역이나 트랜잭션이 갑자기 실패한다면?

웹 컨테이너에 전개하기

웹 컨테이너에 전개된 서블릿 컴포넌트에는 EJB 컴포넌트의 트랜잭션 애트리뷰트 대부분이 부족하다. 하지만, 웹 컨테이너는 RMLT와 LTC 제한 정책 모두를 지원하고, 이 두 가지 모두 ECI 리소스 어댑터에 의해 만들어진 JCA 요청들에 대해 어느 정도의 영향력을 갖고 사용될 수 있다.

1. 같은 트랜잭션 범위 내에서, 서블릿에서 여러 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 미러 트랜잭션의 개별 인스턴스를 사용한다는 것을 알게 될 것이다. 웹 컨테이너 내에서, 각 인터랙션은 후속 요청이 만들어지기 전에 자동 실행되기 때문이다.

같은 트랜잭션 범위에서 실행되는 CICS로 두 개의 요청을 해야 한다면, 두 가지 솔루션이 있다. 첫 번째는, 권장 방법으로서, EJB 컨테이너의 트랜잭션 제어를 사용하는 것이다. (질문 3 참조) 두 번째는 빈 관리 트랜잭션(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를 사용할 때 필요하다. BMT는 Java Transaction API와 UserTransaction 인터페이스를 사용하여 제어되어야 한다. 이는 여러 연결들을 통해 필요한 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();
}

2. SYNCPOINT 명령어를 실행하는 CICS 프로그램에 연결하는 방법은?

SYNCPOINT 명령어(롤백 옵션을 사용하거나 사용하지 않음)를 실행하는 CICS 프로그램은 또 다른 트랜잭션 매니저에 종속될 수 없고, 확장 트랜잭션 또는 글로벌 트랜잭션의 일부가 될 수 없다. 이 트랜잭션 매니저는 DPL 요청을 실행하는 또 다른 CICS 시스템이 될 수 있고, 또는 우리 같은 경우, CICS ECI 리소스 어댑터에 CCI 요청을 만드는 WebSphere Application Server 트랜잭션 매니저가 될 수 있다. 이렇게 제한하는 이유는 프로그램으로 연결된 것이 글로벌 트랜잭션에서는 효력을 발휘하는 리소스 매니저가 되고, 트랜잭션 매니저만(원래의 호출자)는 트랜잭션 조정을 제어할 수 있기 때문이다.

따라서, SYNCPOINT 명령어를 실행하는 CICS 프로그램으로 연결하려면, SYNCONRETURN이 LINK 명령어에 지정되어야 한다. 이는 CICS 서버 프로그램이 클라이언트와는 독립적으로 자신의 작업 단위에서 실행하고 있다는 것을 나타낸다. CCI 호출에 SYNCONRETURN 작동의 사용은 WebSphere Application Server와 연결된 CICS ECI 리소스 어댑터에 의해 동적으로 제어된다. 웹 컨테이너에서 서블릿에서의 호출의 경우, LINK와 SYNCONRETURN이 요청에 필요한 기본 작동이 된다. (질문 1 참조) 반면, EJB 컨테이너에서는, 표 2에 나타난 것처럼, EJB 트랜잭션 애트리뷰트에 대한 비 트랜잭션 속성(Never)을 정의함으로써 이 컨테이너를 활용할 수 있다.

원격 트랜잭션 매니저(이 경우, WebSphere Application Server)에 의해 트랜잭션 제어로부터 CICS 프로그램을 해방시키고, 트랜잭션 결과를 CICS에 위임하기 때문에, SYNCONRETURN 옵션은 유용하다. 이것은 애플리케이션 디자인에 필수적이고, CICS가 모든 복구 가능한 업데이트(CICS/DB2 또는 CICS/VSAM을 통한 업데이트)를 관리한다면 CICS 내에서의 트랜잭션 무결성 역시 관리된다.

EJB 컨테이너에 전개하기

WebSphere Application Server의 EJB 컨테이너는 트랜잭션 컴포넌트의 전개에 이상적으로 맞고, 컨테이너와 빈 관리 트랜잭션 모두를 지원한다. 컨테이너 관리 트랜잭션은 모든 트랜잭션 조정이 J2EE 서버에서 수행된다는 이점이 있고, 애플리케이션 개발자들은 트랜잭션 로직 보다는 비즈니스 로직 개발에 집중할 수 있다. 트랜잭션 컴포넌트의 작동을 제어하기 위해, EJB 컨테이너는 컨테이너 관리 컴포넌트의 트랜잭션 작동을 제어하는데 사용될 수 있는 애트리뷰트를 제공한다. 이 섹션에서는, 세 가지 애트리뷰트를 설명하고, 이들이 CICS ECI 리소스 어댑터와 연결되어 사용되는 방법을 설명하겠다.

3. 같은 트랜잭션 범위 내에서, EJB 컴포넌트에서 다중 ECI 요청이 가능한가?

트랜잭션 애트리뷰트와 트랜잭션 콘텍스트의 초기 상황은 ECI 호출 유형과 CICS로의 호출에 대한 결과 트랜잭션 범위에 영향을 미친다. 표 2는 결과 ECI 호출 유형과 CICS 미러 태스크의 트랜잭션 범위를 설명한 것이다. Long running 특성을 가진 CICS 미러 태스크는 CICS 내에서의 확장된 작업 단위를 나타내고, synconreturn 옵션을 가진 미러 태스크는 CICS 트랜잭션이 EJB 컴포넌트의 콘텍스트와는 다른 트랜잭션 콘텍스트에서 실행되고, 미러 태스크가 각 ECI 호출이 끝난 후에 종료된다는 것을 나타낸다.

4. 글로벌 트랜잭션의 CICS 부분에 ECI 요청을 하는 방법은?

애플리케이션 서버 환경에 따라서, 글로벌 트랜잭션에 참여하는 다른 XA 가능 리소스 매니저가 있다면 네 가지 방법이 있다.

1. CICS TG for z/OS V6.1의 XA 지원은 CICS 영역과 다른 XA 순응 리소스들 간 글로벌 트랜잭션 지원을 제공하기 위해 사용된다. CICS ECI XA 리소스 어댑터는 WebSphere Application Server V6 설정 내에서 사용될 수 있다.

2. WebSphere Application Server for z/OS내의 RRS 글로벌 트랜잭션 지원은 CICS 영역과 다른 XA나 RRS 순응 리소스 매니저들 간 글로벌 트랜잭션 지원을 제공하기 위해 사용된다. 이 기능은 RRS에 기반하고 있고, CICS, CICS TG, WebSphere Application Server가 같은 쥐오스 시스템에서 사용되어야 하고, WebSphere Application Server for z/OS 와 CICS TG for z/OS의 모든 지원 버전들에 사용할 수 있어야 한다.

3. 이 트랜잭션 내에 열거된 XA 리소스 매니저(JDBC 데이터 소스)가 없다면, CICS ECI 리소스 어댑터의 로컬 트랜잭션 지원이 글로벌 트랜잭션 내에서 사용될 수 있다. 글로벌 트랜잭션은 two-phase commit 프로토콜에서 one-phase 최적화를 제공하기 때문에 이것이 가능하고, one-phase commit 흐름은 이 트랜잭션에 개입된 단 하나의 리소스 매니저 브랜치(싱글 리소스)만 있다면 트랜잭션 매니저에 의해 사용된다. 이를 유일한 에이전트 최적화라고 한다. 이는 주로 퍼포먼스 최적화를 위한 것이며, 준비될 필요가 없는 글로벌 트랜잭션의 싱글 one-phase commit 리소스 매니저(CICS ECI 리소스 어댑터를 사용한 연결)를 지원하는 것도 가능하다.

4. WebSphere Application Server V6 (그리고 WebSphere Application Server Enterprise V5)에서 지원하는 Last participant 지원은 싱글 one-phase commit 리소스 매니저(CICS ECI 리소스 어댑터에서의 연결)가 two-phase commit 리소스 매니저를 사용하여 글로벌 트랜잭션에 참여할 수 있도록 한다.

LPS 기능은 확장 전개 디스크립터(XDD)를 통해 EJB 컴포넌트에 대해 실행된다. WebSphere Application Server의 엔터프라이즈 애플리케이션 설정은 Last participant 지원 속성 페이지를 제공하고, 여기에는 Accept 위험 체크박스가 있다. (그림 8)

그림 8. WebSphere Application Server: Last participant 지원

WebSphere Application Server V6 트랜잭션 서비스는 one-phase commit 리소스를 실행하기 전에 추가 로그 엔트리를 작성하여 복구 동안 적절한 보고를 실행하도록 설정될 수 있다. 관리 콘솔에서 Application Servers => Server => Server properties => Transaction Service로 가서, Enable logging for heuristic reporting 체크 박스를 선택한다.

5. z/OS에서 WebSphere Application Server를 사용한다면, 트랜잭션 지원이 달라지는가?

CICS Transaction Gateway가 WebSphere Application Server for z/OS의 로컬 모드에서 사용되면, 글로벌 트랜잭션은 내부 RRS 기능을 사용하여 CICS ECI 리소스에 의해서 지원된다. 이것은 z/OS 환경에 최적화 되어있고 원격 게이트웨이를 사용할 때 two-phase commit에 필요한 XA 트랜잭션 흐름의 오버헤드가 없다.

게다가 WebSphere Application Server for z/OS는 같은 트랜잭션에서 싱글 one-phase commit 리소스와 RRS 리소스를 사용하도록 허용한다. 분산 플랫폼의 WebSphere Application Server와는 달리, LPS XDD 속성들을 지정할 필요가 없다.

WebSphere Application Server for z/OS에 CICS Transaction Gateway에서 제공되는 RRS 글로벌 트랜잭션 지원은 빈 관리 로컬 트랜잭션은 지원하지 않는 다는 점에 주목하라. 질문 1에서 설명한 것처럼, CICS ECI 커넥션 팩토리의 LocalTransaction 인터페이스를 사용하는 것은 지원되지 않는다.

6. z/OS에 CICS TG를 전개하면 어떤 점이 좋은가?

z/OS 상의 CICS TG는 EXCI를 사용하여 CICS에 고속 크로스 메모리 액세스를 제공한다. 이 메커니즘은 MRO 기반 통신 메커니즘이기 때문에, 다른 플랫폼에서는 사용할 수 없다. EXCI 프로토콜을 사용하면 MVS Resource Recovery Services (RRS)를 통해서 two-phase commit 트랜잭션 지원이 가능하다. 이는 CICS TG V6.1에서 XA 지원을 통해 사용할 수 있다.

CICS TG V6.1 for z/OS는 복제된 CICS Transaction Gateway 데몬을 통해 TCP/IP 로드 밸런싱을 지원한다. TCP/IP 포트를 공유하여 높은 쓰루풋과 고가용성을 제공한다.

7. two-phase commit 프로세싱 중에 네트워크 연결이 실패한다면 어떤 일이 발생하는가?

트랜잭션 실행 중에(커미트 프로세싱이 시작되기 전), CICS Transaction Gateway 데몬으로 TCP/IP 네트워크 연결이 실패하면, 이에 대한 공지를 받은 CICS Transaction Gateway 데몬에 의해 이 트랜잭션은 RRS에서 롤백으로 표시된다. 하지만, 커미트 프로세싱 중에 연결이 실패하면, 트랜잭션은 in-doubt 단계에서 중지되고, 데몬은 커미트를 대기하거나, 연결이 다시 이루어지면 트랜잭션 매니저(WebSphere Application Server)에서 백아웃(back-out) 응답을 기다린다.

8. one-phase commit 프로토콜이 two-phase commit 프로토콜 보다 더 이로운 상황이 있는가?

two-phase commit 프로세시가 분산 트랜잭션 지원의 조건이기는 하지만, one-phase commit 프로세스로도 충분한, 또는 더 선호되는 상황도 있다.:

CICS로 단 하나의 호출이 이루어지고, 이 트랜잭션 내에서 복구 가능한 리소스에 대한 업데이트가 없다면, 글로벌 트랜잭션을 사용할 필요가 없다. 이 경우, SYNCONRETURN 옵션을 가진 비 트랜잭션 요청이 사용되어 트랜잭션 영역이 CICS에 대한 엔트리에서 시작되고 리턴 시 종료된다.

글로벌 트랜잭션 내 모든 요청들이 싱글 CICS 시스템을 통해 이루어지면, CICS ECI 리소스 어댑터가 제공하는 one-phase commit 로컬 트랜잭션 지원으로도 충분하다. two-phase commit 작동이 필요 없다. 게다가, WebSphere Application Server의 RMLT를 사용할 때 감소한 네트워크 흐름으로 인해, XA 트랜잭션에 비교해볼 때, 로컬 트랜잭션을 사용하는 요청 퍼포먼스가 더 알맞다. 하지만, XA 프로토콜은 커미트 프로세싱 중 실패에 대한 재동기화 및 복구 로직을 제공하기 때문에 one-phase commit 시나리오에 부가적인 무결성도 제공한다.

9. 로컬 트랜잭션 리소스 어댑터(CICS ECI 리소스 어댑터)가 글로벌 트랜잭션에 추가된다면 어떤 문제가 발생하는가?

로컬 트랜잭션 리소스 어댑터가 XA 리소스 매니저와 함께 글로벌 트랜잭션에 추가된다면, EJB 컨테이너 내에서 예외가 발생한다. two-phase commit 프로세스는 one-phase commit 리소스 매니저를 사용하여 준비 단계를 완료할 수 없게 된다. EJB 컨테이너는 기존 two-phase commit 리소스에 one-phase commit 리소스를 추가하려는 잘못된 시도가 발생했다(An illegal attempt to enlist a one-phase capable resource with existing two-phase capable resources has occurred)는 메시지를 보고한다.

10. ECIRequest 클래스 또는 Common Connector Framework (CCF) 클래스를 WebSphere Application Server에서 사용한다면 어떤 지원을 받을 수 있는가?

WebSphere Application Server V5에서, ECIRequest 클래스와 CCF 클래스는 웹 컨테이너 내에서만 지원되고, 비 확장 논리적 작업 단위로 사용할 때에만 지원된다. 게다가, WebSphere Application Server에서 제공하는 JCA 관리 환경에 참여할 수 없기 때문에, RMLT나 글로벌 트랜잭션에도 참여할 수 없다. 따라서, 이러한 클래스를 사용하는 트랜잭션 요청 애플리케이션들은 신중하게 설계되어(적절한 보상 로직도 활용할 수 있도록 설계되어) 일관성 있는 결과를 낼 수 있어야 한다.

11. CICS 영역이나 트랜잭션이 갑자기 실패한다면?

XA 트랜잭션 프로토콜은 예상된 중지 프로토콜이다. 따라서, 트랜잭션이 진행 중에(커미트 프로세싱이 초기화 되기 전에) 오류가 발생하면, 모든 업데이트가 롤백된다. CICS 하위 시스템 또는 네트워크 중단도 이에 포함된다. 하지만, CICS의 ABEND는 약간 다르게 처리된다. JCA 아키텍처에서, (ABEND를 포함한) 모든 오류는 ResourceException로서 J2EE 컴포넌트로 간다. 이 예외가 잡히지 않으면, 기본적으로 CICS에 의해 수행되는 모든 작업들을 포함하여 트랜잭션이 실행되어 ABEND에 이르게 된다. CICS 트랜잭션 ABEND가 자동 롤백을 실행하도록 하고 싶다면 두 가지 방법이 있다.:

a. CICS TS V2와 이후 버전에서, EXCI 옵션 테이블 DFHXCOPT에는 새로운 옵션인 ABENDBKOUT={NO|YES}가 추가되었다. 이 옵션은 CICS 트랜잭션 ABEND가 RRS Unit of Recovery의 자동 롤백을 실행할 것인지의 여부를 설정하고 CICS 작업 단위 내에서 이루어진 모든 업데이트의 백아웃을 실행한다. 이 옵션은 CICS TS V3.1에는 APAR PK17426, CICS TS V2.2와 V2.3에서는 APAR PK17427로 도입되었다. (APAR는 EXCI에만 적용되기 때문에 CICS TG on z/OS에서만 사용된다.)

b. J2EE 애플리케이션이 ResourceException을 받으면, 이 예외가 CICS 트랜잭션 ABEND를 나타내는지, 심지어 특별한 CICS ABEND 코드가 무엇인지도 조사할 수 있다. 일단 탐지 되면, 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 트랜잭션 관리 콘트랙트이다. 이 콘트랙트는 다양한 요소들의 영향을 받는다. 웹 컨테이너를 사용하는지 아니면 EJB 컨테이너를 사용하는지 여부, EJB 트랜잭션 애트리뷰트, LTC 설정, WebSphere Application Server에서 XA나 RRS를 사용하는지 여부 등이 영향을 미친다.

기사의 원문보기

ㆍIBM WebSphere Developer Technical Journal: Exploiting the J2EE Connector Architecture

참고자료

ㆍWebSphere Application Server Information Centers

ㆍCICS Transaction Gateway Library

ㆍCICS Transaction Server for z/OS Library

ㆍCICS Transaction Gateway V6.1 enhancements

ㆍIntegrating WebSphere Application Server and CICS using the JCA

ㆍTransactional services in WebSphere Application Server Enterprise V5

ㆍConfiguring and using XA distributed transactions in WebSphere Studio

ㆍRedbook: CICS Transaction Gateway for z/OS Version 6.1