jeus - tmaxsoft · 2019. 4. 9. · jeus transaction service 3 jeus transaction service jeus는...

WhitepaperWhitepaperWhitepaperWhitepaper

JEUS Transaction Service

Copyrightⓒ 2001 TmaxSoft Co.,Ltd. All Right Reserved.

JEUS Transaction Service 1

Contents

About JEUS Transaction Service ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 3

I. JEUS Transaction System의 구조

1. Containers ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 4

2. XADataSource ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 7

3. JEUS Transaction Manager ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 7

4. Communication Manager ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 8

5. DataSource ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 9

II. 트랜잭션 처리 Mechanism

1. 트랜잭션의 시작 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 10

2. Root Coordinator 영역에서의 데이터베이스로의 접근 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 10

3. 트랜잭션 propagation ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 11

4. Sub Coordinator 영역에서의 데이터베이스로의 접근 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 11

5. 트랜잭션의 Commit ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 12

III. Timeout Mechanism

1. 트랜잭션 진행 중의 Timeout ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 15

1) Active Timeout ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 15

2) Prepare Timeout of Sub Coordinator ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 16

3) Prepare Timeout of Resource Manager ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 16

4) Prepared Timeout ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 17

5) Commit Timeout of Sub Coordinator ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 17

6) Commit Timeout of Resource Manager ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 18

2. Recovery에서의 Timeout ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 19

1) Timeout of Uncompleted Transaction Entry ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 19

2) Timeout of Global Decision Retrieval ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 19

IV. Logging

1. XADataSource의 Logging ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 20

2. 2 Phase Commit Protocol의 Logging ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 20

3. Log 파일 관리 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 21


V. Recovery ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 22

1. RM1 Failure ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 24

2. Root Coordinator Failure ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 25

3. Sub Coordinator Failure ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 26

4. RM2 Failure ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 27

VI. Performance Issues

1. Presumed Abort ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 29

2. Branch Joining Optimization ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 29

3. Commit Protocol Optimzation ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 30

4. Local Transaction Optimization ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 31

5. Connection Pool Delegation ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 32

6. Heuristic Rollback ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 33


JEUS Transaction Service

JEUS는 J2EE에 기술된 트랜잭션 서비스를 완벽히 지원한다.

JEUS는 트랜잭션 서비스를 제공하기 위하여 low level의

Transaction Manager와 high level의 JTA 인터페이스 mapper

를 가지고 있으며, RM과의 연결과 관리를 위한 XADataSource를

제공한다. EJB Container는 EJB specification에 정의된 기능들을

제공하여 유저는 Bean-Managed Transaction Demarcation 을

이용하여 직접 트랜잭션의 시작과 끝을 선언할 수 도 있고,

Container-Managed Transaction Demarcation을 사용하여 EJB

Container에게 트랜잭션의 관리를 위임할 수도 있다.

JEUS Transaction Manager는 트랜잭션 시스템의 중심으로 복구

를 위한 log를 별도로 관리하며 Configuration 파일을 통해 그

동작을 제어할 수 있다.


I. JEUS Transaction System의의의의 구조구조구조구조

JEUS는 기본적으로 J2EE 에 기술된 트랜잭션 시스템 아키텍쳐를 따르

고 있다. 아래의 그림은 JEUS Transaction System의 전체 구조를 보

여 준다.

Containers

JEUSJEUSJEUSJEUS의의의의 Web Container Web Container Web Container Web Container와와와와 EJB Container EJB Container EJB Container EJB Container는는는는 Servlet, JSP, EJB Servlet, JSP, EJB Servlet, JSP, EJB Servlet, JSP, EJB

specifispecifispecifispecificationcationcationcation을을을을 준수하여준수하여준수하여준수하여 작성된작성된작성된작성된 AP AP AP AP에에에에 대하여대하여대하여대하여 트랜잭션트랜잭션트랜잭션트랜잭션 서비스를서비스를서비스를서비스를 제제제제

공한다공한다공한다공한다.... Servlet, JSP에서는 UserTransaction을 통하여 AP에서 트랜잭

션의 시작과 종료를 지시할 수 있으며 EJB에서는 Bean-Managed

Transaction Demarcation 과 Container-Managed Transaction

Demarcation 을 통해 트랜잭션의 시작과 종료를 수행할 수 있다.

Communication Manager

(RMI or IIOP)

JEUS Transaction

Manager

JTA Mapper between JEUS Transaction Manager and Application

XADataSource

(JDBC Driver)

XAConnection

Pool Containers

Transaction

Transaction Manager

XAResource

UserTransaction

Connection

Transaction

Transaction Manager

Application Program

Synchronization

XAConnection

Transaction Context

Propagation

<JEUS Transaction System>


Servlet, JSP, Bean-Managed Transaction Demarcation EJB에서는

AP 코드에 명시적으로 begin() 함수를 호출하는 코드가 있어

Transaction Manager에게 트랜잭션의 시작을 알리게 된다. 이후에 AP

가 XADataSource로부터 Connection을 얻어 데이터베이스에 접근하면

이것이 Transaction Manager에게 등록이 되어지며, AP에서 commit()

을 호출하게 되면 Transaction Manager가 RM들과의 통신을 통해 현

재 트랜잭션의 commit/rollback 여부를 결정하고 결정된 대로 데이터

베이스에 반영한다. Container-Managed Transaction Demarcation에

비해 이 방식은 Container가 해주는 일이 적어서 exception 발생시에

이를 처리하여 주고, setRollbackOnly()를 하여주는 정도이다. 만약 이

러한 방식으로 트랜잭션 관리가 이루어지고 있는 서비스를 호출한 쓰

레드가 이미 트랜잭션 하나를 수행중이면 그 트랜잭션은 무조건

suspend가 된다.

ContainerContainerContainerContainer----Managed Transaction Demarcation EJBManaged Transaction Demarcation EJBManaged Transaction Demarcation EJBManaged Transaction Demarcation EJB에서는에서는에서는에서는 AP AP AP AP는는는는 단지단지단지단지

Deployment DescriptorDeployment DescriptorDeployment DescriptorDeployment Descriptor에에에에 각각각각 함수의함수의함수의함수의 트랜잭션트랜잭션트랜잭션트랜잭션 특성을특성을특성을특성을 선언하기만선언하기만선언하기만선언하기만 하하하하

면면면면 Container Container Container Container가가가가 이이이이 특성에특성에특성에특성에 맞추어맞추어맞추어맞추어 트랜잭션을트랜잭션을트랜잭션을트랜잭션을 중지중지중지중지, , , , 새로새로새로새로 시작시키기시작시키기시작시키기시작시키기

도도도도 한다한다한다한다.... 선택할 수 있는 트랜잭션의 종류에는 다음의 6 가지가 있다.

NotSupported

함수를 수행하는 쓰레드가 이미 다른 트랜잭션을 수행하고 있는 중이

면 이것을 suspend시켜 함수는 항상 트랜잭션에 관련이 없이 수행되도

록 한다. Suspend된 트랜잭션은 함수 수행이 종료되면 Container에 의

해 resume 된다.

Required

만약 함수를 수행하는 쓰레드가 트랜잭션을 수행하는 중이 아니면 새

로운 트랜잭션을 시작시켜 함수를 수행하도록 하고, 함수가 이미 트랜

잭션을 수행중이면 그 트랜잭션을 가지고 함수를 수행할 수 있도록 하

여 함수가 항상 트랜잭션과 관련되어 있는 상태에서 수행될 수 있도록

한다. 새로 생성된 트랜잭션은 함수의 수행이 끝나면 Container에 의

해 commit 된다.


Supports

함수를 수행하는 쓰레드의 트랜잭션 상태를 그대로 유지한다. 쓰레드가

트랜잭션과 관련이 없으면 없는 채로 함수를 수행하고 트랜잭션과 관

련이 있으면 그 트랜잭션을 그대로 유지하면서 함수를 수행한다.

RequiredNew

함수를 수행하는 쓰레드의 이전 트랜잭션 상태에 관계없이 Container

가 항상 새로운 쓰레드를 생성하여 함수가 수행되도록 한다. 만약 쓰레

드가 이미 다른 트랜잭션과 관련이 되어 있다면 그 트랜잭션을

suspend 시킨다. 함수 수행이 종료되면 새로 시작되었던 트랜잭션을

commit 시키고, suspend 시켜 둔 트랜잭션이 있다면 그것을 resume

시켜준다.

Mandatory

함수를 수행하는 쓰레드가 트랜잭션과 관련이 되어있지 않다면

exception을 함수 호출자에게 던진다. 관련이 되어 있다면 그 트랜잭

션을 그대로 유지시킨 채 함수가 수행되도록 한다. 함수는 항상 트랜잭

션과 관련이 되어 수행된다.

Never

함수를 수행하는 쓰레드가 트랜잭션과 관련이 되어 있으면 exception

을 던진다. 함수는 항상 트랜잭션과 관련이 없는 상태로 수행이 된다.

Container-Managed Transaction Demarcation에서는 AP는 트랜잭션

의 시작과 종료에 관여할 수 없으며 AP가 트랜잭션 수행중 이상을 발

견하면 setRollbackOnly()을 수행하여 트랜잭션이 rollback되도록 한다.

함수 수행중 exception이 발생하였을 경우에도 Container에 의해서 처

리 된다.


XADataSource

기본적으로기본적으로기본적으로기본적으로 XADataSource XADataSource XADataSource XADataSource는는는는 RM RM RM RM과의과의과의과의 채널채널채널채널 역할을역할을역할을역할을 하는하는하는하는 JDBC JDBC JDBC JDBC

connectionconnectionconnectionconnection을을을을 감싸고감싸고감싸고감싸고 있어있어있어있어 트랜잭션트랜잭션트랜잭션트랜잭션 시스템시스템시스템시스템 내의내의내의내의 다른다른다른다른 모듈과모듈과모듈과모듈과 RM RM RM RM과의과의과의과의

통신채널통신채널통신채널통신채널 제공을제공을제공을제공을 담당하고담당하고담당하고담당하고 있다있다있다있다.... 여기에 2 가지 기능을 추가로 제공하

는데 첫째는 Connection pooling이다. AP가 데이터베이스에 접근하려

고 할 때 Connection을 매번 새로 설정하는 것이 아니라 기존에 한 번

사용했던 Connection이 있는지 먼저 살펴보고 pool에 Connection이

있으면 미리 연결된 Connection을 재사용한다. Connection 사용이 끝

나면 AP는 Connection을 close 하고 XADataSource는 close된 것을

보고 Connection을 pool에 넣어 재사용이 가능하도록 한다. 다른 하나

는 AP가 트랜잭션을 진행하면서 XADataSource로부터 Connnection을

얻어 데이터베이스에 접근하게 된다. XADataSource는 AP에

Connection을 건내주기 전에 Connection을 TM에게 등록하는 기능이

다. 또 AP가 Connection 사용을 마쳐 close를 수행하면 이때 TM에게

트랜잭션과 관련된 작업이 종료되었음을 알려준다.

JEUS Transaction Manager

JEUS Transaction ManagerJEUS Transaction ManagerJEUS Transaction ManagerJEUS Transaction Manager는는는는 pure java transaction manager pure java transaction manager pure java transaction manager pure java transaction manager이다이다이다이다....

TM은 트랜잭션 시스템의 중심으로 global transaction의 시작과 끝을

관리하며 시스템 장애 발생시에 복구도 담당하고 있다. AP가 트랜잭션

을 시작하면 이것이 TM에게 알려진다. TM은 이 트랜잭션에게 XID를

부여하고 이 트랜잭션을 담당할 Root-Coordinator을 생성한다. 트랜잭

션의 진행이 하나의 TM이 관리하는 영역내에서 이루어지는 동안은 이

Coordinator가 XADataSource로부터의 RM에 관한 정보등 트랜잭션에

관한 정보를 모두 관리하게 된다. 만약 트랜잭션이 TM이 관리하는 영

역을 벗어나 작업하려고 하면 TM은 Communication Manager의 도움

을 받아 현재의 트랜잭션에 관한 정보를 함수 호출을 위한 패킷에 실

어 보낸다. 이 정보를 호출을 받는 Container의 CM이 받아 이것을

TM에게 넘겨주면 이것을 해석하여 트랜잭션 정보를 얻어내고 얻어낸

정보를 바탕으로 이 트랜잭션을 담당할 새로운 Sub-Coordinator를 만


들어 낸다. 이 Sub-Coordinator는 자신이 담당하는 영역 내에서 트랜

잭션 관련 작업 정보를 수집한다. 트랜잭션 관련 작업이 끝났음을 알게

되면 TM은 Root-Coordinator와 Sub-Coordinator에 기록된 정보를

바탕으로 RM들에게 Two-Phase Commit을 수행하여 global

transaction을 완료시킨다.

TM은 시스템 장애시에도 global transaction의 무결성이 깨지지 않도

록 보장하여 주어야 한다. 이를 위해 JEUS Transaction Manager에서

는 Two-Phase Commit과 관련하여 Log Manager에서 트랜잭션에 대

한 logging을 한다. 각 TM은 자신이 관리했던 트랜잭션들이 한번이라

도 사용한 적이 있는 XADataSource에 관한 정보를 기록한다. Log는

각 TM당 하나씩 관리하게 된다. Restart시에는 완전한 종료작업이 이

루어져야 하는 트랜잭션의 리스트들을 RM들로부터 받은 후 남겨진 이

전의 Log와 현재 동작하고 있는 TM들로부터 정보를 모아 이들에 대

한 종료작업을 진행한다. 장애 복구시에 기록된 XADataSource들을 복

구하여 RM들과의 채널을 연후 복구 작업을 진행한다. 각각의 트랜잭션

에 대해서는 Presumed Abort를 기본으로 하여 logging을 한다. 즉

commit된 트랜잭션에 대해서만 log를 남기며 log의 량이 일정 이상되

면 Log Manager가 자동으로 Check-pointing을 한다.

Communication Manager

Communication ManagerCommunication ManagerCommunication ManagerCommunication Manager의의의의 주된주된주된주된 역할은역할은역할은역할은 트랜잭션이트랜잭션이트랜잭션이트랜잭션이 복수복수복수복수 개의개의개의개의 TM TM TM TM

영역에영역에영역에영역에 걸쳐걸쳐걸쳐걸쳐 진행될진행될진행될진행될 경우경우경우경우 각각각각 TM TM TM TM들에게들에게들에게들에게 진행중인진행중인진행중인진행중인 트랜잭션에트랜잭션에트랜잭션에트랜잭션에 대한대한대한대한 정정정정

보를보를보를보를 건내주는건내주는건내주는건내주는 역할을역할을역할을역할을 하는하는하는하는 것이다것이다것이다것이다.... JEUS는 이를 위해 Transaction

Context를 전달해주는 EJB Stub를 만들어 사용한다. 이 EJB Stub는

EJB의 deployment 시에 생성된다.


DataSource

DataSourceDataSourceDataSourceDataSource는는는는 데이터베이스로의데이터베이스로의데이터베이스로의데이터베이스로의 Connection Connection Connection Connection을을을을 제공하여제공하여제공하여제공하여 주는주는주는주는 JDBC JDBC JDBC JDBC

DriverDriverDriverDriver이다이다이다이다.... 데이터 베이스 벤더나 써드 파티 벤더, 또는 JEUS 자체로

제공하는 JDBC Driver 등 어떤 것이든 JDBC 표준을 준수하는 것이면

사용가능 하며 DataSource 클래스를 구현한 클래스를 가지고 있어야

한다. 기본적으로 트랜잭션 시스템에 사용되는 DataSource는

XADataSource 이다. 하지만 성능 개선을 위해서 경우에 따라서

ConnectionPoolDataSource 가 사용될 수 도 있다.


II. 트랜잭션트랜잭션트랜잭션트랜잭션 처리처리처리처리 Mechanism

JEUS Transaction Manager는 복수 개의 Transaction Manager 관리

영역을 거치면 복수 개의 데이터베이스 인스턴스와 작업을 진행하는

트랜잭션에 대하여 ACID가 보장되도록 global 트랜잭션 처리를 하여준

다. Transaction Manager의 일반적인 트랜잭션 처리 과정은 다음의 절

차를 따른다.

트랜잭션의트랜잭션의트랜잭션의트랜잭션의 시작시작시작시작

1) 하나의 트랜잭션은 어플리케이션 프로그램이 명시적으로 그 시작

을 demarcation 하거나 어플리케이션 프로그램을 관리하는 Container

에서 대신 시작 시킬 수 있다.

2) 트랜잭션 시작 시에 Transaction Manager 는 새로 시작되는 트랜

잭션만의 unique 한 XID를 부여하고 이 트랜잭션 관련 정보를 관리하

기 위한 Root Coordinator를 하나 생성한다. 그리고, Transaction

Manager는 트랜잭션의 시작에 사용된 쓰레드에 이 XID를 tag로 붙여

놓게 된다.

Root Coordinator 영역에서의영역에서의영역에서의영역에서의 데이터데이터데이터데이터 베이스로의베이스로의베이스로의베이스로의 접근접근접근접근

3) 트랜잭션 진행 중 어플리케이션이 Connection Pool 에 접근하여

데이터베이스로의 Connection을 얻으려고 하면 Connection Pool은

Transaction Manager 에게 지정된 XID의 트랜잭션이 데이터베이스에

작업을 수행할 것임을 알리고 Transaction Manager는 이 정보를

Coordinator 에 기록하여 둔다.


트랜잭션트랜잭션트랜잭션트랜잭션 propagation

4) 트랜잭션이 현재의 Transaction Manager의 관리 영역을 벗어나게

되면 Communication Manager가 이것을 감지한다. JEUS 트랜잭션 시

스템에서는 이 동작을 통신 Stub 들이 한다. 통신 stub은 어플리케이

션의 서비스 호출시에 현재의 쓰레드에 tag로 붙어있는 XID를

piggybacking 하여 다른 서비스 모듈로 전송하게 된다.

5) 다른 서비스 모듈이 이 호출을 받으면 먼저 통신 skeleton 이

piggybacking 된 XID 가 있는지를 조사하여 있으면 자신이 포함되어

있는 관리 영역을 담당하는 또 다른 Transaction Manager 에게 트랜

잭션이 propagation 되어 왔음을 알린다.

6) Transaction Manager는 이 propagation 된 트랜잭션을 담당할

Sub Coordinator 를 하나 생성한 후 현재의 쓰레드에 XID를 tag로 붙

인다.

Sub Coordinator 영역에서의영역에서의영역에서의영역에서의 데이터베이스로의데이터베이스로의데이터베이스로의데이터베이스로의 접근접근접근접근

7) 어플리케이션이 Connection Pool 에 접근하였을 때의 동작은 기본

적으로 3) 에서와 같다. 단 Sub Coordinator 에서는 XID를 분석하여

Root Coordinator의 네트웍 상의 위치를 찾아 Root Coordinator에게

자신을 등록한다. Root Coordinator는 Sub Coordinator를 데이터베이

스 인스턴스와 마찬가지로 Resource Manager 로 보고 등록을 받아들

인다.


트랜잭션의트랜잭션의트랜잭션의트랜잭션의 Commit

8) 어플리케이션이 트랜잭션 작업을 종료하고 commit을 하게 되면

Transaction Manager는 먼저 현재 등록된 Resource Manager의 수를

보고 2 phase commit을 할 것인지 1 phase commit 을 할 것인지 결

정한다.

Resource Manager가 복수 개일 경우

9) 등록된 Resource Manager 에게 prepare 메시지를 보낸다. Root

Coordinator는 실제 Resource Manager와 Sub Coordinator 를 같게

다룬다. 이 prepare 메시지는 parallel하게 전송된다.

10) prepare 메시지를 받은 Sub Coordinator는 자신에게 등록된

Resource Manager 들에게 다시 prepare 메시지를 보낸 후 이 결과를

모아 Root Coordinator 에게 응답을 보낸다.

Application

Connection

Pool

JDBC

drive

Stub

Transaction Manager

(Root Coordinator)

DB

2)

3)

Containe

1)

1)

4)

Application Connection

Pool

JDBC

drive

DB

7)

Containe

6)

5)

7)

8) Transaction

Manager

(Sub Coordinator)

Skeleton


11) Root Coordinator는 prepare 메시지에 대한 응답을 모두 모아 해

당 트랜잭션에 대한 global decision을 내린다. 모두가 commit을 응답

하였으면 commit, 하나라도 rollback을 응답하였으면 rollback 이 된

다. Readonly로 응답을 한 Resource Manager는 global Decision 에

영향을 미치지 못한다. 결정된 global decision은 log 파일에 기록된다.

12) 결정된 global decision 에 따라 commit 또는 rollback 메시지가

전송된다. Readonly 로 응답하였던 Resource Manager 에게는 아무

메시지도 전송되지 않는다.

13) Sub Coordinator는 Root Coordinator로부터 global decision을

받아 자신에게 등록된 Resource Manager 에게 재전송 한다.

14) Root Coordinator는 commit/rollback 에 대한 처리가 완료되었음

을 Resource Manager 또는 Sub Coordinator로부터 확인한 후 처리

완료를 logging 하고 이 트랜잭션 관련된 리소스들을 반환한다.

Resource Manager 가 한 개일 경우

9) 등록된 Resource Manager 에게 commit 메시지를 바로 전송한다.

Resource Manager는 commit 처리를 하고 처리 결과가 commit 인지

rollback 인지 알려주는데 이것이 바로 이 트랜잭션의 global decision

결과가 된다.

10) 사용된 리소스들을 반환하고 트랜잭션을 종료한다.


Resource Manager 가 없을 경우

9) 트랜잭션 진행 중에 데이터베이스 인스턴스에 한번도 접근하지 않

았다. Commit 관련하여 처리할 것이 없으므로 바로 사용된 리소스들을

반환하고 트랜잭션을 종료한다.

Root Coordinator

Sub Coordinator

Resource Manager

(DB2)

Resource Manager

(DB1)

9) 12) 9) 12)

10) 13)

11) 14)


III. Timeout Mechanism

트랜잭션트랜잭션트랜잭션트랜잭션 시스템의시스템의시스템의시스템의 주요한주요한주요한주요한 기능기능기능기능 중중중중 하나는하나는하나는하나는 시스템시스템시스템시스템 failure failure failure failure 시에도시에도시에도시에도 트랜트랜트랜트랜

잭션이잭션이잭션이잭션이 ACID ACID ACID ACID 특성을특성을특성을특성을 준수하며준수하며준수하며준수하며 수행되도록수행되도록수행되도록수행되도록 보장하는보장하는보장하는보장하는 것이다것이다것이다것이다.... JEUS 트

랜잭션 시스템에서는 시스템의 failure 상황을 감지하고 이에 대처하기

위하여 다양한 timeout 기능을 두고 있다. Timeout 기능은 크게 트랜

잭션 진행 중에 사용되는 timeout 기능과 recovery 시에 적용되는

timeout 기능이 있다.

트랜잭션트랜잭션트랜잭션트랜잭션 진행진행진행진행 중의중의중의중의 Timeout

하나의 트랜잭션은 복수 개의 Transaction Manager 관리 영역과 복수

개의 데이터베이스 인스턴스에 걸쳐 진행될 수 있다. 또 commit 시에

는 이들과의 긴밀한 통신을 통해 global 트랜잭션을 종료하게 된다. 만

약 이러한 작업 중 트랜잭션에 연관된 Transaction Manager 또는

Resource Manager 에서 failure 가 발생한다면 해당 트랜잭션은 더

이상 진행될 수 없을 것이다. 이러한 사항을 감지하여 적절한 조치를

취해주기 위하여 JEUS 트랜잭션 시스템에서는 다음의 6 가지의

Timeout 을 두고 있다.

1) Active Timeout 1) Active Timeout 1) Active Timeout 1) Active Timeout

트랜잭션을 시작한 어플리케이션은 active timeout 으로 지정된 시간

이내에 commit을 호출해야 한다. 만약 시스템 failure 등에 의하여 정

해진 시간내에 commit() 이 호출되지 않으면 Transaction Manager 는

그 트랜잭션을 자동으로 rollback 시킨다. 어플리케이션은 트랜잭션

시작 전에 UserTransaction의 setTransactionTimeout()을 호출함으로

써 이 값을 코드 내에서 결정할 수 있으며, 만약 지정하지 않으면

Transaction Manager 설정의 TMActiveTimeout 값이 적용된다.


2) Prepare Timeout of Sub Coordinator 2) Prepare Timeout of Sub Coordinator 2) Prepare Timeout of Sub Coordinator 2) Prepare Timeout of Sub Coordinator

어플리케이션이 active timeout 이전에 commit()을 호출하여 트랜잭션

이 무사히 commit 단계에 들어서게 되면 Root Coordinator는 등록된

Resource Manager 또는 Sub Coordinator 에게 prepare 메시지를 전

송하게 된다. Sub Coordinator 에게 prepare 메시지를 전송한 후 설정

된 prepare timeout 이전에 응답 메시지를 받지 못하면 Root

Coordinator는 해당 Sub Coordinator의 응답을 rollback으로 간주하고

처리를 진행한다. Transaction Manager 설정의 TMPrepareTimeout

의 값이 적용된다.

3) Prepare Timeout of Resource Manager 3) Prepare Timeout of Resource Manager 3) Prepare Timeout of Resource Manager 3) Prepare Timeout of Resource Manager

prepare 메시지가 Resource Manager 에게 전송되었을 때 Resource

Manager가 Connection Pool의 Operation Timeout 내에 응답을 보내

지 않으면 이 Resource Manager 로부터의 응답은 rollback으로 간주

된다. 이 값은 Connection Pool 설정의 OpertionTimeout 값으로 결정

된다.


4) Prepared Timeout 4) Prepared Timeout 4) Prepared Timeout 4) Prepared Timeout

Prepare 메시지를 받은 Sub Coordinator 가 이에 대한 응답을 Root

Coordinator 에게 보낸 후 Root Coordinator 로부터 commit 또는

rollback의 global decision을 받게 되는데 prepared timeout 동안 응

답을 받지 못하면 timeout 값을 주기로 반복하여 prepare 에 대한 응

답 메시지를 보내 global decision 받기를 시도한다. Transaction

Manager의 TMPreparedTimeout 설정 값이 적용된다.

5) Commit Timeout of Sub Coordinator 5) Commit Timeout of Sub Coordinator 5) Commit Timeout of Sub Coordinator 5) Commit Timeout of Sub Coordinator

Root Coordinator 는 global decision을 결정한 후 이것을 등록된 Sub

Coordinator 또는 Resource Manager 에게 알린다. Root Coordinator

가 Sub Coordinator 에게 global decision을 전달한 후 commit

timeout(Time out으로 설정된 수) 이내에 응답을 받지 못하면 해당

Sub Coordinator 가 global decision에 따른 트랜잭션 처리작업을 제대

로 종료하지 못한 것으로 판단하고 이 트랜잭션은 uncompleted 트랜

잭션 리스트에 기록하여 둔다. 이 리스트의 사용방법은 recovery 관련

설명에서 하도록 한다. Transaction Manager의 TMCommitTimeout

값이 적용된다.


6) Commit Timeout of Resource Manager6) Commit Timeout of Resource Manager6) Commit Timeout of Resource Manager6) Commit Timeout of Resource Manager

Root Coordinator 가 Resource Manager에게 global decision을 전달

한 후 Resource Manager Connection Pool의 Operation Timeout 내

에 응답을 보내지 않으면 이 Resource Manager가 global decision에

따른 트랜잭션 처리작업을 정상적으로 종료하지 못한 것으로 판단하고

이 트랜잭션은 uncompleted 트랜잭션 리스트에 기록하여 둔다. 이 값

은 Connection Pool 설정의 OpertionTimeout 값으로 결정된다.

2)

4)

1)

3)

3)

5)

6) 5)

Root

Coordinator

Sub

Coordinator

Resource

Manager 2

Resource

Manager 1

Active

Phase

Prepare

Phase

Commit

Phase


Recovery 에서의에서의에서의에서의 Timeout

Recovery 시에 사용되는 timeout은 다음의 두 가지 이다.

1) Timeout of Uncompleted Transaction Entry1) Timeout of Uncompleted Transaction Entry1) Timeout of Uncompleted Transaction Entry1) Timeout of Uncompleted Transaction Entry

Uncompleted 트랜잭션 리스트에는 commit 처리를 완전히 하지 못한

트랜잭션의 XID와 global decision 이 기록되어 있다. 이 정보는 트랜

잭션의 recovery 시에 사용되며 자세한 설명은 뒤에서 한다.

Transaction Manager 는 이 정보를 지정된 시간 동안만 보관하고 있

다가 해당 엔트리를 삭제한다. 이렇게 하여 적정한 양의 엔트리 만이

트랜잭션 시스템에 의해 관리되도록 한다. Transaction Manager 의

TMUncompletedTimeout 설정 값을 사용한다.

2) Timeout of Global Decision Retrieval2) Timeout of Global Decision Retrieval2) Timeout of Global Decision Retrieval2) Timeout of Global Decision Retrieval

시스템 failure 발생 후 Transaction Manager 가 재시작 되면 log 디

렉토리에 남아 있는 log 파일들을 읽어 recovery를 시작한다. JEUS

Transaction Manager는 자신의 관리 영역에서 사용되었던

XADataSource 의 정보를 남겨두는데 이것으로부터 XADataSource들

을 다시 생성하여 이것들을 통해 데이터베이스 접근한 후 prepare는

되었으나 commit 또는 rollback 은 되지 못한 트랜잭션의 XID 리스트

를 얻어오게 된다. 이 XID를 분석하여 트랜잭션의 Root Coordinator의

위치를 얻어낸 후 Root Coordinator 에게 global decision 결과를 묻게

되는데 만약 지정된 timeout 이전에 global decision 응답을 얻지 못하

면 설정에 따라 동작하게 된다. heuristic rollback 을 설정하여 놓았다

면 rollback을 하고 설정이 되어 있지 않다면 시스템에 log를 남겨 시

스템 관리자가 처리하도록 한다. Heuristic rollback 에 관한 설정은 뒤

에서 설명한다. Transaction Manager 의 TMRecoveryTiemout 설정

값을 적용한다.


IV. Logging

JEUS Transaction Manager 에서는 크게 두 가지 정보를 Logging 한

다.

XADataSource 의의의의 logging

하나의 Transaction Manager 가 관리하는 영역 내에서 사용되어지는

모든 XADataSource에 관련된 정보가 logging 된다. 이 정보는 시스템

failure 발생 후의 recovery 시에 Transaction Manager 가 logging

된 XADataSource 관련 정보를 보고 그 XADataSource를 통해 데이터

베이스에 접근하여 prepare 메시지는 받았지만 commit 또는 rollback

메시지를 받지 못한 트랜잭션의 리스트를 얻어오는데 사용된다. 이렇게

얻어진 트랜잭션의 리스트는 트랜잭션 recovery 알고리즘에 사용되어

진다.

2 Phase Commit Protocol 의의의의 logging

2 phase commit 수행 중에 발생하는 logging 이다. Logging 정보는

트랜잭션 recovery 시에 사용되며 prepare phase는 진행하였지만

commit/rollback phase는 마치지 못한 트랜잭션에 대해 prepare

phase 의 최종 결과가 commit 인지 rollback 인지에 관한 정보를 가

지고 있다.


Log 파일파일파일파일 관리관리관리관리

JEUS Transaction Manager는 log 파일의 크기를 적절한 수준으로 유

지하기 위하여 파일에 대한 정리 작업을 주기적으로 수행한다.

XADataSource 에 관련된 log의 경우는 시스템 설정에 따라 그 크기가

거의 정해지므로 추가적으로 해줄 일이 없지만 2 phase commit 관련

log는 시간이 지남에 따라 계속적으로 증가하게 된다. 이렇게 증가하는

log를 log 파일에 계속적으로 기록하기만 하면 파일의 크기가 무한히

증가할 뿐만 아니라 recovery 시에 log 파일을 검색하기 위하여 많은

시간을 소모하여야만 한다. 이러한 문제를 해결하기 위해 JEUS

Transaction Manager 에서는 log 파일에 대한 checkpointing을 주기

적으로 수행하여 준다. 지정된 시간이 되면 Transaction Manager 는

그 시점에서 2phase commit 에 대한 처리가 완료되지 못한 트랜잭션

들에 관한 정보를 새로운 log 파일에 기록하고 이전의 log 파일은 삭제

시킨다. 이렇게 함으로써 이미 처리가 완료된 트랜잭션에 관한 log를

제거 시킬 수 있다.


V. Recovery

JEUS 트랜잭션 시스템은 시스템 failure 가 발생하여도 logging 된 정

보를 바탕으로 트랜잭션의 ACID 가 유지되도록 트랜잭션을 처리한다.

Recovery의 핵심이 되는 두 요소는 timeout 기능과 log 관리이다. 위

에서 설명된 다양한 timeout 기능을 통해 시스템의 failure를 감지하여

내며 log 정보를 재 가공하여 트랜잭션의 모든 branch가 global

decision에 따라 처리되도록 한다. JEUS 트랜잭션 시스템은 2 phase

commit protocol을 global 트랜잭션 처리의 기본 메커니즘으로 사용하

고 있으며, 시스템 failure 에 의해 protocol 이 정상적으로 진행되지

못하는 다양한 상황들에 대해 효율적으로 대처한다. 주목할 것은 2

phase commit 상에서의 복잡한 recovery 처리 과정들은 Connection

Pool이 XADataSourece 타입일 경우에만 요구된다는 것이다. Local

Transaction Optimization 이 적용되었을 경우는 Resource Manager

가 오직 하나 이므로 global 트랜잭션의 ACID를 맞춰 주기위한

recovery 과정이 필요없다. Local Transaction Optimization 에 대해서

는 뒤에서 자세히 설명한다.

다음의 그림에서 트랜잭션은 2 개의 Transaction Manager 관리 영역

과 2개의 데이터베이스 인스턴스를 걸쳐 진행되었다. 트랜잭션 commit

과정에 참여하는 각 모듈들이 failure 상태가 된다 하더라도 전체 트랜

Root Coordinator

Sub Coordinator

RM 2

RM 1


잭션 시스템은 failure 를 극복하고 트랜잭션의 ACID를 유지하여 준다.

2 phase commit protocol로 처리되는 트랜잭션은 크게 5단계를 거쳐

처리가 완료된다.

단계 1 : 트랜잭션이 어플리케이션 코드에 의하여 시작된 이후부터

commit()이 호출된 시기까지

단계 2 : 각 Sub Coordinator와 Resource Manager로 prepare 메시지

가 전달되어 데이터베이스 인스턴스에서 prepare 처리 작업이 완료되

기 까지

단계 3 : prepare 에 대한 응답이 Root Coordinator 에게 모아져

global decision이 내려지기까지

단계 4 : Sub Coordinator와 Resource Manager가 global decision을

받아 트랜잭션 처리를 실제로 수행하기까지

단계 5 : Root Coordinator가 각 Sub Coordinator와 Resource

Manager로부터 트랜잭션 처리가 완료되었다는 메시지를 다 모아

global 트랜잭션의 완료를 확인하고 작업을 종료하기까지


시스템 failure 는 어느 단계에서나 어느 트랜잭션 참가 모듈에서나 발

생할 수 있다. JEUS 트랜잭션 시스템에서 failure 상황에 대한 전체 트

랜잭션 시스템의 대처 메커니즘은 다음과 같다.

1) RM1 failure1) RM1 failure1) RM1 failure1) RM1 failure

Root Coordinator 와 직접 연결을 맺고 있는 Resource Manager 에서

failure 가 발생하였을 경우다. RM1 은 Root Coordinator 와만 연결을

맺고 있어 Root Coordinator에서 failure 에 대한 대처를 하게 된다.

단계 1,2 에서 failure 가 발생하면 RM1 은 prepare가 되지 않은 상

태에서 데이터베이스에 문제가 생겼으므로 자동적으로 rollback 될 것

이고, Root Coordinator 에서는 RM1 의 prepare 에 대한 응답을

rollback으로 하여 작업을 진행할 것이다.

단계 3, 4에서 failure 가 발생하면 데이터베이스는 prepare 상태에 있

어 트랜잭션 중 이루어졌던 데이터 변경은 계속 유효하지만 global

decision을 받지 못해 최종 처리를 하지 못하고 죽은 것이다. 만약 단

계 3에서 failure가 발생하였다면 Root Coordinator는 RM1의 prepare

Active

Phase

Prepare

Phase

Commit

Phase

1)

2)

5)

3)

4)

Root Coordinator

Or

Sub Coordinator

Sub Coordinator

Or

Resource Manager


응답을 rollback으로 처리하고, 단계 4에서 failure 가 발생하였다면

RM1의 정상 응답이 포함된 global decision을 결정하게 된다. 하지만

어느 경우에도 RM1으로 global decision을 전송하는데 실패할 것이고

이 경우 Root Coordinator는 이 트랜잭션의 XID와 global decision을

uncompleted 트랜잭션 리스트에 기록하여 둔다. JEUS 트랜잭션 시스

템에서는 데이터베이스의 restart를 감지하지 않는다. 감지를 위한 오

버헤드가 이로부터 얻을 수 있는 이익보다 작기 때문이다. 시스템 관리

자는 데이터베이스를 restart 시킨 후 dbpooladmin 의 resync 를 이

용하여 Root Coordinator에서 RM1으로 연결하기 위해 사용했던

Connection Pool을 refresh 시키면 이 때 이 신호가 Transaction

Manager 에게까지 전달되며 uncompleted 트랜잭션 리스트에 기록된

정보에 의거하여 RM1으로 global decision 이 다시 전달된다.

단계 5에서 failure 가 발생하였을 경우 Root Coordinator는 트랜잭션

XID와 global decision을 uncompleted 트랜잭션 리스트에 저장하게

된다. 사실 데이터베이스에게 이미 트랜잭션의 global decision이 전달

되었고 이것이 반영되었으므로 이러한 처리는 무의미하지만 Root

Coordinator 입장에서는 failure 가 단계 4에서 발생하였는지 단계 5

에서 발생하였는지 항상 구분할 수 는 없으므로 이렇게 한다. 이렇게

기록된 uncompleted 트랜잭션 리스트 상의 엔트리는

TMUncompletedTO 값 만큼 시스템에 의해 관리되다가 삭제된다. 이

시간 이후에 데이터베이스가 복구 된다면 dbpooladmin의 resync 시에

presumed abort 방식의 logging 에 의해 rollback으로 처리되어 버리

므로 TMUncompletedTO 의 설정에 주의하여야 한다. Presumed

abort 방식의 logging 에 대해서는 뒤에서 설명한다.

2) Root Coordinator failure 2) Root Coordinator failure 2) Root Coordinator failure 2) Root Coordinator failure

Root Coordinator 에 failure 가 발생하면 RM1 과 Sub Coordinator가

각기 recovery 알고리즘에 의해 동작해주어야 한다.

단계 1,2 에서 failure 가 발생하면 Sub Coordinator 에서는 active

timeout 이 발생하여 rollback으로 처리가 되고, RM1는 데이터베이스

자체적으로 데이터 수정을 무효화한다.


단계 3,4 에서 failure 발생시 RM1은 변경된 데이터를 prepare 된 상

태로 유지하게 된다. Root Coordinator 가 동작 하였었던 Transaction

Manager 가 restart 되었을 때 log 디렉토리에서 자신의 관리 영역에

서 사용되었던 Connection Pool 들의 정보를 읽어들여 Connection

Pool들과 연결된 Resource Manager 들에게 접근하여 prepare는 되었

으나 최종 처리는 되지 않는 트랜잭션의 XID 리스트를 받아오는데 이

때 RM1 으로부터도 리스트를 얻어오게 된다. XID 를 분석하면 Root

Coordinator 가 자신이었음을 알게 되고 log 디렉토리로부터 global

decision을 logging 해 놓았던 파일을 읽어 분석하여 global decision

을 얻어낸뒤 이것을 RM1 에게 전달한다. 만약 단계 3에서 failure 가

발생하였다면 presumed abort 방식의 logging 메커니즘에 의해 global

decision은 rollback이 된다. Sub Coordinator에서는 설정 사항에 따라

다르게 동작한다. Heuristic rollback을 false로 설정하였다면 Root

Coordinator가 복구될 때 까지 계속 global decision을 prepared

timeout을 주기로 polling 하게 되며, true 로 설정되어 있으면 일정 회

수를(현재 구현에서는 2회) 추가로 Root Coordinator에게 prepare 메

시지를 보낸 후 그래도 응답이 없으면 rollback 처리를 한다.

단계 5에서 failure 가 발생하면 Sub Coordinator 와 RM1 모두 트랜

잭션 관련 처리는 마친 상태이므로 global 트랜잭션으로서의 처리에는

문제가 없다. 단 Root Coordinator의 log 에 이 트랜잭션이 무사히 완

료되었다는 log가 남지 않았으므로 Root Coordinator의 restart 시에

이 트랜잭션은 uncompleted 트랜잭션 리스트에 기록되게 된다. 이 기

록은 TMUncompletedTimeout 후에 자동 삭제된다.

3) Sub Coordinator failure 3) Sub Coordinator failure 3) Sub Coordinator failure 3) Sub Coordinator failure

Sub Coordinator에서 failure 가 발생하면 Root Coordinator 와 RM2

가 recovery 처리를 해주어야 한다.

단계 1, 2 에서 failure 가 발생하면 RM2는 데이터베이스 자체적으로

데이터 수정을 무효화하고, Root Coordinator는 prepare 에 대한 응답

을 받지 못하므로 이 Sub Coordinator의 응답을 rollback으로 처리하

게 된다.


단계 3, 4 에서 failure 가 발생하면 RM2 에서는 데이터의 변경사항이

prepare 된 상태로 있고, Root Coordinator에서는 결정된 global

decision을 Sub Coordinator로 전달하지 못하고 있는 상태이다. 만약

단계 3의 prepare에 대한 응답 메시지가 Root 에 도달하지 못했다면

global decision은 rollback이 된다. Root Coordinator는 global

decision을 Sub Coordinator로 전달하려고 하지만 Sub Coordinator가

응답하지 않으므로 이 트랜잭션을 uncompleted 트랜잭션 리스트에 기

록하여 둔다. RM2의 prepare 상태의 데이터는 Sub Coordinator가 동

작했던 Transaction Manager가 restart 되면서 log 디렉토리에서 자신

의 관리 영역에서 사용되었던 Connection Pool 들의 정보를 읽어들여

Connection Pool들과 연결된 Resource Manager 들에게 접근하여

prepare는 되었으나 최종 처리는 되지 않는 트랜잭션의 XID 리스트를

받아오는데 이 때 RM2 으로부터도 리스트를 얻어오게 된다. Sub

Coordinator는 얻어진 XID 를 분석하여 Root Coordinator의 위치를

알아낸 뒤 global decision을 묻는다. Root Coordinator 는

uncompleted 트랜잭션 리스트로부터 global decision을 찾아 전달하고

Sub Coordinator는 이것을 RM2에게 전달한다.

단계 5 에서 failure가 발생하면 RM2와 Sub Coordinator는 global 트

랜잭션 관련 처리를 마친 상태이다. 하지만 Root Coordinator 로서는

global decision을 받아 처리를 완료하였는지 아닌지, 즉 단계 4에서

failure가 발생하였는지 단계 5에서 문제가 발생하였는지 항상 정확히

알 수 는 없으므로 uncompleted 트랜잭션 리스트에 이 트랜잭션을 기

록하게 된다. 이 기록은 TMUncompletedTimeout 후에 자동 삭제된다.

4) RM2 failure 4) RM2 failure 4) RM2 failure 4) RM2 failure

RM2 의 failure 에 대한 Sub Coordinator의 대처 메커니즘은 RM1 에

대한 Root Coordinator의 대처 메커니즘과 완전히 동일하다. RM2 에

게는 Sub Coordinator 가 Root Coordinator로 보이고, Sub

Coordinator 또한 그렇게 보이도록 동작하여야 하기 때문이다.

단계 1, 2 에서 failure 가 발생하면 RM2 의 prepare 되지 않은 데이

터는 데이터베이스에 의해 자동 삭제되며, Sub Coordinator 는 RM2

의 응답을 rollback으로 처리하여 Root Coordinator 에게 알려주게 된


다.

단계 3, 4 에서 failure 가 발생하면 Sub Coordinator는 global

decision을 RM2 에게 전달할 수 없게 되고 Root Coordinator 에게는

최종처리가 제대로 되지 않았음을 알리게 된다. Root Coordinator는 이

트랜잭션을 uncompleted 트랜잭션 리스트에 기록하게 되고, RM2 의

restart후에 시스템 관리자가 dbpooladmin의 resync를 이용하여 Sub

Coordinator의 RM2에 대한 Connection Pool을 refresh 시키면 이 신

호가 Sub Coordinator에게 전달되고 Sub Coordinator는 RM2로부터

prepare는 되었으나 최종 처리는 되지 않은 트랜잭션의 XID 리스트를

받아 XID를 분석하여 Root Coordinator의 위치를 알아내어 global

decision을 얻어 RM2에게 전달하게 된다.

단계 5 에서 failure 가 발생하면 RM2는 global 트랜잭션 관련 처리를

마친 상태이므로 트랜잭션 ACID 상의 문제는 없지만 Sub Coordinator

입장에서는 failure가 단계 4에서 발생한 것인지 단계 5에서 발생한 것

인지 알 수 없으므로 Root Coordinator에게 global 트랜잭션의 최종

처리가 완전하지 않았음을 알리고 Root Coordinator 에서는

uncompleted 트랜잭션 리스트에 이 트랜잭션을 기록하여 둔다. 이 기

록은 TMUncompletedTimeout 후에 자동 삭제된다.


VI. Performance Issues

Presumed Abort

Transaction Manager는 트랜잭션이 복수 개의 Transaction Manager

관리 영역과 복수 개의 데이터베이스 인스턴스를 거쳐 진행되었을 때

commit 시에 2 phase commit protocol을 사용하게 된다. 2 phase

commit 에서는 prepare phase 와 commit phase 사이에서 global

decision을 반드시 log 파일에 저장하여야 한다. JEUS Transaction

Manager는 presumed abort 방식으로 log를 남겨 logging의 양을 줄

이고 있다. Presumed abort에서는 global decision의 commit 일 때만

log을 남기고 rollback일 때는 log를 남기지 않음으로써 logging의 양

을 줄인다.

Branch Joining Optimization

트랜잭션 진행 중에 하나의 Connection을 통해 이루어진 데이터베이스

작업은 트랜잭션 상에 하나의 트랜잭션 branch를 이루게 된다. 만약

어플리케이션 프로그램이 하나의 트랜잭션 진행 중 5 개의

Connection을 통해 데이터베이스 작업을 진행하였다면 5개의 트랜잭

션 branch 가 생성되게 된다. 이 트랜잭션의 commit 시에

Transaction Manager 는 각각의 branch 에 대해 prepare, commit 메

시지를 보내므로 branch 의 숫자는 트랜잭션 전체 성능에 큰 영향을

미친다.

JEUS Transaction Manager는 트랜잭션 진행 중에 접근하였던 데이터

베이스 인스턴스들의 정보를 유지하고 있다. 어플리케이션 프로그램이

데이터베이스 에 접근하게 되면 현재 진행 중인 트랜잭션이 이전에 같

은 데이터베이스에 접근한 적이 있는지 찾아본다. 사용하였던 기록이

있으면 이전에 그 데이터베이스 접근 시에 사용하였던 branch에 현재

의 데이터베이스 작업에 대한 branch를 ‘join’ 하여 준다. Join 을 1


회 적용하면 트랜잭션의 commit 시에 다루어야 할 branch의 수가 하

나 줄어들게 되므로 성능의 향상을 얻을 수 있다. 두 개의 Branch가

join 되려면 두 가지 조건이 충족되어야 한다. 하나는 두 개의 branch

가 하나의 데이터베이스 인스턴스에 대한 작업이어야 한다는 것이고,

또 하나는 두 개의 branch 가 하나의 Transaction Manager의 관리

영역 내에 있어야 한다는 것이다. JEUS Transaction 시스템에서 하나

의 Transaction Manager는 하나의 JVM 을 관리 영역으로 한다.

Commit Protocol Optimization

JEUS Transaction Manager 에서 기본적으로 사용하는 commit

protocol은 2 phase commit protocol 이다. 2 phase commit protocol

은 트랜잭션 commit 시에 트랜잭션에 포함되었던 branch들에 대해

prepare와 commit 메시지를 모두 보낸다. JEUS Transaction Manager

는 트랜잭션의 branch 수와 상황에 따라 두 가지 optimization을 수행

한다.

첫째는 1 phase commit protocol의 사용이다. 만약 트랜잭션 진행 중

에 branch 가 하나 밖에 생성이 되지 않았다면 복수 개의 데이터베이

스에 대한 일관성에 대한 고려가 필요 없어진다. 이 경우 해당 branch

에 prepare, commit의 절차를 거치지 않고 바로 1 phase commit을 하

게 된다. 이 branch의 commit 또는 rollback 결정이 곧 바로 전체 트

랜잭션의 commit, rollback 결정이 된다. 이렇게 하면 prepare 메시지

를 전송하지 않으며, 2 phase commit protocol 에서 요구되는 global

commit/rollback 결정에 대한 로깅의 필요성도 사라져 성능의 향상을

얻을 수 있다.

둘째는 read-only branch의 처리이다. Prepare 메시지를 받은 데이터

베이스가 응답으로 commit 또는 rollback 이 아닌 readonly 를 응답

하였을 경우 JEUS Transaction Manager는 이것을 인식하여 이

branch 에게 더 이상의 메시지를 보내지 않게 된다. 이 기능은 데이터

베이스가 readonly 응답을 줄 수 있어야 가능한 것으로 JEUS

Transaction Manager 에서는 단지 readonly 응답을 인식하여 그 이후

에 이 branch로 commit 또는 rollback 메시지를 보내지 않는 동작만

해준다. Commit/rollback 메시지가 전송되지 않으므로 성능 향상을 이


룰 수 있다.

Local Transaction Optimization

기본적으로 JEUS 트랜잭션 시스템은 XADataSource 를 기반으로 동

작한다. XADataSource 로부터 얻어진 XAConnection 을 사용하는 복

수 개의 작업을 트랜잭션으로 묶어 진행하게 되면 이 트랜잭션이 이기

종 데이터베이스에 대해 작업을 하고, 복수 개의 JEUS Transaction

Manager 관리 영역을 통과한다 하더라도 모두 하나의 global 트랜잭

션을 묶여져 처리된다. 이러한 동작방식은 다양하고 복잡한 어플리케이

션 프로그램에 대해 트랜잭션 환경을 제공하지만 실제 어플리케이션

프로그램들은 대게 하나의 데이터베이스 인스턴스에 대해 작업을 수행

하고, 그 트랜잭션의 실행 영역 또한 JEUS Transaction Manager 하나

의 관리 영역을 벋어나지 않는 것이 보통이다. 이 경우 JEUS 트랜잭션

시스템에서는 XAConnection 이 아닌 PooledConnection 을 이용하여

보다 효율적으로 트랜잭션을 수행한다.

트랜잭션 수행을 XADataSource로 하여야 하는 이유는 트랜잭션이 복

수 개의 데이터베이스에 접근하였을 때 이 트랜잭션의 commit 시점에

서 이들 데이터베이스 인스턴스들과 2 phase commit 을 진행하여야

하기 때문이다. 만약 트랜잭션이 하나의 데이터베이스 인스턴스와 작업

을 진행한다면 앞에서 설명되었듯이 branch joining과 1 phase commit

프로토콜에 의해서 commit 한번으로도 commit 이 처리될 수 있다.

Local Transaction Optimization 에서는 이 보다 한 걸음 더 나가 트랜

잭션을 Global 트랜잭션이 아닌 Local 트랜잭션으로 처리하는 것이다.

어플리케이션은 트랜잭션의 시작과 종료를 선언하고 트랜잭션 진행 중

복수 개의 Connection을 얻어 작업을 진행하는 등 Global 트랜잭션과

똑같이 작업을 수행하지만 JEUS Connection Pool 이 JEUS

Transaction Manager 의 도움을 받아 트랜잭션의 진행을 추적해 가며

하나의 PooledConnection 이 계속 사용되도록 Connection을 별도로

관리한다. 이렇게 하면 commit 과정에서 local 트랜잭션 commit을 사

용할 수 있을 뿐만 아니라 XAConnection 관리와 관련된 추가적 메시

지 교환을 하지 않아도 되어 성능을 보다 향상시킬 수 있다.

Local Transaction Optimization의 개념은 J2EE 와 Connector


Architecture 에서 제시된 바 있다. JEUS 트랜잭션 시스템의 Local

Transaction Optimization 은 이루고자 하는 바는 같지만 그 구현 방

식이 다르다. Connector Architecture 에서는 하나의 트랜잭션이 local

트랜잭션으로 처리가 가능한가를 Connector 시스템이 자동으로 감지

하지만 JEUS 트랜잭션 시스템에서는 어플리케이션 시스템 관리자가

Local Transaction Optimization 용 Connection Pool을 따로 설정하고

이 pool을 기반으로 트랜잭션 작업이 이루어져야만 한다. 이렇게 구현

한 이유는 관리자가 이러한 설정을 해 줌으로써 Local Transaction

Optimization 처리가 훨씬 간단하고 효율적으로 구현될 수 있으며 이

러한 설정이 매우 간단하게 이루어 질 수 있기 때문이다. Connection

Pool의 타입을 LocalXADataSource 로 설정하여 주기만 하면 된다.

Connection Pool Delegation

앞에서도 설명하였듯 트랜잭션은 기본적으로 XADataSource를 기반으

로 동작한다. Connection Pool Delegation은 XADataSource가 아닌

PooledConnectionDataSource를 생성하여 이것을 XADataSource의

Delegate으로 설정하여 두는 것이다. XADataSource가 어플리케이션

프로그램으로부터 Connection 요청을 받았을 때 XADataSource는 먼

저 이 요청이 트랜잭션 진행 중에 이루어진 것인지를 먼저 검사한다.

만약 트랜잭션 중에 이루어진 것이면 XAConnection 하나를 pool로부

터 빼내어 건내준다. 만약 요청이 트랜잭션과 관계없이 이루어 진 것이

라면 이 요청은 설정된 PooledConnectionDataSource로 delegation

되게 된다. PooledConnectionDataSource 에서는 autocommit이 true

로 설정된 PooledConnection 하나를 건내주게 된다. 이 메커니즘은 두

가지 목적을 가지고 있다.

첫째, 트랜잭션 관련 JDBC 표준을 완전히 준수하지 못하는 JDBC

driver 들의 동작을 바로 잡기 위한 것이다. JDBC 표준에서는

XAConnection 이 트랜잭션과 연관되어 동작 할 때는 global 트랜잭션

동작을 하여야 하지만 그렇지 않을 경우는 local 트랜잭션을 처리하는

일반 Connection 과 완전히 같게 동작하여야 한다고 정의하고 있다.

하지만 실제 시스템에 많이 사용되는 데이터베이스 벤더로부터의 free

JDBC Driver 는 이러한 동작을 완전히 지원하지 못하기도 한다. JEUS


Connection Pool 에서는 어플리케이션이 Connection을 요청하는 순간

에 트랜잭션 진행 중인지 아닌지를 검사하여 상황에 맞는 Connection

을 건내준다. 이러한 방식이 모든 경우에 Connection 이 JDBC 표준을

준수한 것과 완전히 같도록 해주지는 못하지만 대부분의 경우에 JDBC

표준을 준수한 Connection을 사용한 것과 같게 동작하도록 해 준다.

둘째, 트랜잭션이 진행 중이지 않을 경우는 autocommit 이 되도록 설

정한 Connection 이 건내지게 하여 어플리케이션 프로그램의 성능 향

상의 가능성을 제공한다. 특정 어플리케이션의 경우 하나의 작업에 대

해 조건이 만족되면 global 트랜잭션이 아닌 autocommit 되어지는

local 트랜잭션으로 처리하는 것이 훨씬 효율적일 때가 있다.

Connection Pool Delegation을 설정하여 두면 어플리케이션에서는 단

지 특정 조건이 만족되는지 확인하여 트랜잭션을 시작하거나 아니거나

하기만 하면 Connection Pool 이 상황에 맞는 Connection 이 사용되

어 질 수 있도록 하여 준다. 이 기능은 어플리케이션 프로그램 작성자

가 이러한 특성을 정확히 알고 사용하여 한다.

Heuristic Rollback

Transaction Manager 가 2 phase commit protocol 수행 중에

prepared timeout이 발생하게 되면 기본 대응 방법은 Sub

Coordinator 가 prepared timeout을 주기로 Root Coordinator 에게

global decision을 얻기 위한 메시지를 보내는 것이다. 이것이 트랜잭

션의 ACID를 보장하는 방식의 동작이기는 하지만 문제는 Root

Coordinator가 오랫동안 복구되지 못한 상태로 있는다면 데이터베이스

내의 데이터에 대한 locking 시간이 길어져 시스템이 거의 동작을 못

하게 된다. 이러한 현상은 많은 수의 사용자 요청을 처리하는 시스템일

수록 큰 문제가 된다. 이럴 경우에는 트랜잭션의 일관성이 깨질 수 있

다 하더라도 차라리 heuristic하게 commit 또는 rollback을 선택하여

처리해버리고 다른 작업을 진행하는 것이 전체 시스템을 살리고 시스

템 failure 상황에서 사용자 요청 처리 능력을 유지하는 방법이 될 수

있다. 이렇게 처리된 트랜잭션은 필요에 따라서 시스템 관리자가 데이

터 조정 작업을 해주어야 할 수 도 있다. JEUS 트랜잭션 시스템에서는

이렇게 heuristic 한 결정을 할 것인지 아니면 계속 Root Coordinator


로 메시지를 보낼 것이지를 설정할 수 있으며 heuristic 한 방식을 할

경우는 rollback을 시키도록 되어 있다.

jeus - tmaxsoft · 2019. 4. 9. · jeus transaction service 3 jeus transaction service jeus는...

Documents