출처 : http://www.terms.co.kr/2PC.htm
2PC (two-phase commit) ; 2단계 커미트
분산 컴퓨팅 환경에서 사용자의 트랜잭션을 처리하는데 있어, 트랜잭션 관리 프로그램은 트랜잭션에 관련된 모든 데이터베이스가 성공적으로 수정되었음을 확실하게 하기 위하여 2단계 커미트라고 불리는 프로토콜을 사용할 수 있다. 만일 데이터베이스의 수정이 성공적으로 이루어지지 않은 경우에, 그 트랜잭션은 롤백 상태가 되어 트랜잭션이 개시되기 이전의 상태로 되돌아간다. 만약 그 트랜잭션이 관련된 컴퓨터들에 의해 성공적으로 종료되었다면, 모든 데이터베이스의 수정을 위한 커미트가 이루어지며, 새로운 트랜잭션들이 자유로이 접근할 수 있도록 자원에 걸려 있던 로크들이 풀어진다. 아래에 이 프로토콜에 관한 간략한 설명이 있다.
|
응용 프로그래머에게 있어서의 2단계 커미트는 BEGIN, COMMIT, 그리고 필요한 경우 ROLLBACK 등의 프로그램 요청을 함으로써 구현된다.
---------------------------------------------------------------------------------------------------------------------------------------------------
EJB에서의 2PC
2-phase commit이 지원되려면 다음과 같은 3가지 환경이 모두 충족되어야 한다.
1. Resource Manager(주로 데이타베이스)가 2-phase commit를 지원해야 한다.
현재 Oracle 8i는 이상은 지원한다. 다른 DB는 DB 메뉴얼을 살펴볼 필요가 있음.
2. WAS(Web Application Server)가 2-phase commit을 지원해야 한다.
2-phase commit을 하려면 transaction Manager가 resource manager사이를 통제해야
한다. 즉 transaction manager가 WAS에 내장되어 있어야 한다.
3. JDBC Driver가 2-phase commit를 지원해야 한다.
JDBC2.0 까지는 2-phase commit를 지원하지 않는다.
Weblogic의 경우 Weblogic Enterprise 5.1 이상부터oracle용 2-phase commit를 지원하는 jdbc driver를 자체적으로 내장하고 있다.
---------------------------------------------------------------------------------------------------------------------------------------------------
출처 : http://luke.egloos.com/1483419
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 프로세스를 초기화 할 때에만 가능하다.
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 리소스에 성공적으로 위임한다.
