2단계 커밋 프로토콜
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
2단계 커밋 프로토콜은 분산 데이터베이스 시스템에서 트랜잭션의 원자성을 보장하기 위한 프로토콜이다. 코디네이터와 참가자로 구성된 환경에서, 트랜잭션 커밋 여부를 결정하기 위해 두 단계, 즉 커밋 요청 단계와 커밋 단계로 진행된다. 이 프로토콜은 각 노드의 안정적 저장소와 쓰기 전 로그를 전제로 하며, 커밋 요청 단계에서 참가자들의 투표를 통해 커밋 또는 롤백을 결정한다. 성공적인 경우 모든 참여자에게 커밋 메시지를 전송하고, 실패 시에는 롤백 메시지를 보낸다. 2단계 커밋은 구현이 간단하지만, 코디네이터의 장애 발생 시 블로킹 문제와 단일 실패 지점의 위험성을 가진다는 단점이 있다. 이러한 단점을 보완하기 위해 다양한 최적화 기법이 연구되고 있으며, 분산 환경에서 트랜잭션 관리를 위해 활용된다.
더 읽어볼만한 페이지
- 트랜잭션 처리 - 온라인 트랜잭션 처리
온라인 트랜잭션 처리(OLTP)는 실시간 데이터베이스 트랜잭션 처리 방식으로, 가용성, 속도, 동시성, 내구성을 목표로 은행, 항공사, 전자 상거래 등에서 활용된다. - 트랜잭션 처리 - CICS
CICS는 IBM에서 개발한 온라인 트랜잭션 처리 시스템으로, 다양한 산업 분야에서 대규모 트랜잭션 처리를 위해 사용되며, COBOL, PL/I, C, Java 등 다양한 프로그래밍 언어를 지원한다. - 데이터 관리 - 데이터 센터
데이터센터는 컴퓨터 시스템 및 관련 장비와 지원 인프라를 수용하는 시설로, 기술 발전에 따라 규모와 중요성이 확대되었으며, 에너지 효율과 보안을 고려하여 설계 및 운영되고, TIA-942 표준에 따른 티어 분류와 친환경 기술 도입이 이루어지고 있다. - 데이터 관리 - 정보 아키텍처
정보 아키텍처는 정보 시스템 및 정보 기술 분야에서 공유 정보 환경의 구조적 설계를 의미하며, 웹사이트, 소프트웨어 등의 구성과 레이블링을 포함하여 검색 용이성과 사용성을 지원하고, 도서관정보학에 기원을 두고 있다.
| 2단계 커밋 프로토콜 | |
|---|---|
| 기본 정보 | |
| 이름 | 2단계 커밋 프로토콜 |
| 다른 이름 | 2PC (Two-Phase Commit Protocol) 트랜잭션 커밋 프로토콜 |
| 개요 | |
| 유형 | 분산 트랜잭션 프로토콜 |
| 목적 | 분산 컴퓨팅 환경에서 데이터베이스 트랜잭션의 ACID 속성을 보장 모든 참여자가 트랜잭션을 커밋하거나 롤백하도록 보장 |
| 참여자 | 코디네이터 (Coordinator): 트랜잭션 관리자 참여자 (Participants): 데이터베이스, 메시지 큐 등 |
| 프로토콜 단계 | |
| 1단계 (준비 단계) | 코디네이터가 모든 참여자에게 트랜잭션 준비 요청을 보냄 참여자는 트랜잭션을 준비하고, 커밋 또는 롤백 가능 여부를 코디네이터에게 응답 |
| 2단계 (커밋 단계) | 코디네이터가 모든 참여자의 응답을 확인 모든 참여자가 커밋 가능: 코디네이터는 모든 참여자에게 커밋 명령을 보냄 하나 이상의 참여자가 커밋 불가능: 코디네이터는 모든 참여자에게 롤백 명령을 보냄 |
| 장점 | |
| 신뢰성 | 분산 환경에서 데이터 일관성을 보장 |
| 단순성 | 구현이 비교적 간단 |
| 단점 | |
| 블로킹 | 코디네이터 또는 참여자 장애 발생 시, 트랜잭션이 블로킹될 수 있음 성능 저하 및 가용성 문제 발생 가능 |
| 복잡성 | 참여자가 많을수록 프로토콜 복잡도가 증가 |
| 대안 | |
| 다른 프로토콜 | 3단계 커밋 프로토콜 (3PC) Paxos Raft |
2. 전제 조건
2단계 커밋 프로토콜은 다음과 같은 환경을 가정한다.
- 각 노드에는 안정적 저장소가 있고, 쓰기 전 로그가 있다.
- 어떤 노드도 영원히 충돌하지 않는다.
- 쓰기 전 로그의 데이터는 충돌 시 절대 손실되거나 손상되지 않는다.
- 두 노드 간에는 서로 통신할 수 있다.
마지막 가정은 네트워크 통신이 일반적으로 재라우팅될 수 있기 때문에 크게 제한적이지 않다. 처음 두 가정은 훨씬 더 강력하다. 노드가 완전히 파괴되면 데이터가 손실될 수 있기 때문이다.
3. 기본 알고리즘
2단계 커밋 프로토콜은 크게 커밋 요청 단계(Commit-Request Phase, Voting Phase)와 커밋 단계(Commit Phase, Completion Phase)로 구성된다.
기본적인 알고리즘의 진행 과정은 다음과 같다.[10]
| 조정자 (Coordinator) | 참여자 (Cohort) |
|---|---|
| `QUERY TO COMMIT`를 보냄 | |
| `VOTE YES/NO`로 응답 (prepare*/abort*) | |
| `COMMIT/ROLLBACK`을 보냄 (commit*/abort*) | |
| `ACKNOWLEDGMENT`로 응답 (commit*/abort*) | |
| 종료 |
`*` 표시는 레코드가 안정적인 저장소에 강제 기록됨을 의미한다.
3. 1. 커밋 요청 단계 (Voting Phase)
조정자(Coordinator)는 모든 참여자(Participant, Cohort)에게 트랜잭션 커밋 가능 여부를 질의(QUERY TO COMMIT)한다.[10] 각 참여자는 질의를 받으면 트랜잭션을 실행하고, 자신의 실행 취소(Undo) 로그와 재실행 로그에 항목을 기록한다.[10]각 참여자는 트랜잭션이 성공적으로 완료될 수 있으면 "동의"(VOTE YES, 준비 완료) 메시지를, 실패하면 "중단"(VOTE NO, ABORT) 메시지를 조정자에게 보낸다.[10] 조정자는 모든 참여자로부터 응답을 받을 때까지 대기한다.[10]
3. 2. 커밋 단계 (Commit Phase)
조정자(Coordinator)는 참여자(Cohort)에게 `QUERY TO COMMIT` 메시지를 보내 트랜잭션 커밋 가능 여부를 묻는다.[10] 참여자는 `VOTE YES` 또는 `VOTE NO` 메시지로 응답하며, 각각 커밋 준비 완료 또는 거부를 나타낸다. 이때 `*` 표시는 레코드가 안정적인 저장소에 기록됨을 의미한다.조정자는 참여자의 응답에 따라 `COMMIT` 또는 `ROLLBACK` 메시지를 보내 트랜잭션을 커밋하거나 롤백하도록 지시한다. 참여자는 이에 대한 응답으로 `ACKNOWLEDGMENT` 메시지를 보낸다.
커밋 단계의 성공과 실패에 대한 자세한 내용은 하위 문단을 참고할 수 있다.
3. 2. 1. 성공 (Success)
조정자가 커밋 요청 단계에서 모든 참여자로부터 동의 메시지를 수신한 경우:[10]1. 조정자는 모든 참여자에게 커밋 메시지를 보낸다.
2. 각 참여자는 작업을 완료하고, 트랜잭션 동안 보유했던 모든 잠금 및 자원을 해제한다.
3. 각 참여자는 조정자에게 승인 메시지를 보낸다.
4. 조정자는 모든 승인이 수신되면 트랜잭션을 완료한다.
3. 2. 2. 실패 (Failure)
참여자 중 한 명이라도 "아니오"로 투표하거나 조정자의 시간 초과가 만료되면 다음과 같이 진행된다.[10]# 조정자는 모든 참여자에게 롤백 메시지를 보낸다.
# 각 참여자는 실행 취소 로그를 사용하여 트랜잭션을 실행 취소하고, 트랜잭션 중에 보유했던 리소스와 잠금을 해제한다.
# 각 참여자는 조정자에게 응답을 보낸다.
# 조정자는 모든 응답을 받으면 트랜잭션을 실행 취소한다.
「중지」 메시지로 응답한 참가자가 있는 경우도 위와 동일하게 진행된다.[10]
# 조정자는 모든 참여자에게 "롤백하라"는 메시지를 보낸다.
# 각 참여자는 Undo 로그를 사용하여 트랜잭션을 수행하기 전의 상태로 되돌리고, 트랜잭션 중에 보유했던 모든 잠금과 자원을 해제한다.
# 각 참여자는 조정자에게 "완료 응답" 메시지를 보낸다.
# 조정자는 모든 참여자로부터 완료 응답을 받으면 트랜잭션이 완료된 것으로 간주한다.
4. 형식적 명세
2단계 커밋은 다양한 형식적 방법(Formal Methods) 시스템의 입문 예제로 널리 사용되는 고전적인 예시이다.
형식적 명세는 안전성(Safety) 및 활성(Liveness) 속성에 대해 시스템의 유효성을 검사하기 위해 모델 검사(Model Checking)를 할 수 있다. 테스트와 달리 형식적 검증 도구는 정리 증명 및 모델 검사와 같은 기술을 사용하여 모든 가능한 시나리오에서 정확성을 보장한다.
다음은 FizzBee 언어로 작성된 2단계 커밋 프로토콜에 대한 명세이다. 다음 명세는 `always assertion`으로 지정된 안전 속성만을 명시한다. 즉, 하나의 참가자가 커밋되었지만 다른 참가자가 중단된 경우는 절대 발생하지 않는다.
deadlock_detection: false
NUM_PARTICIPANTS = 2
role Coordinator:
action Init:
self.prepared = set()
self.state = "init"
action Write:
if self.state != "init":
return
self.state = "working"
# Phase 1
for p in participants:
vote = p.Prepare()
if vote == 'aborted':
# One participant aborted, start Phase 2: Failure case
self.Abort()
return
self.prepared.add(p.ID)
# Phase 2: Every participant responded success
self.Commit()
func Abort():
self.state = "aborted"
for p in participants:
p.Abort()
func Commit():
if self.state == 'working' and len(self.prepared) == len(participants):
self.state = 'committed'
for p in participants:
p.Commit()
role Participant:
action Init:
self.state = "working"
func Prepare():
if self.state != 'working':
return self.state
oneof:
self.state = 'prepared'
self.state = 'aborted'
return self.state
func Commit():
self.state = 'committed'
func Abort():
self.state = 'aborted'
always assertion ParticipantsConsistent:
for p1 in participants:
for p2 in participants:
if p1.state == 'committed' and p2.state == 'aborted':
return False
return True
action Init:
participants = []
for i in range(NUM_PARTICIPANTS):
p = Participant(ID=i)
participants.append(p)
coordinator = Coordinator()
이 형식적 명세는 https://fizzbee.io/play FizzBee 온라인 플레이그라운드를 사용하여 검증할 수 있다.
'''활성 속성:'''
일반적으로 예상되는 하나의 활성 속성은, 일단 시작된 모든 트랜잭션은 커밋되거나 중단되어야 한다는 것이다.
5. 시퀀스 다이어그램
2단계 커밋 프로토콜의 동작 과정을 시퀀스 다이어그램으로 표현하면 다음과 같다.
코디네이터는 커밋 요청 단계에서 참여자들에게 쿼리를 커밋하도록 요청(QUERY TO COMMIT)한다.[10] 참여자들은 준비가 되면 VOTE YES, 그렇지 않으면 VOTE NO를 보낸다(VOTE YES/NO).[10] 코디네이터는 커밋 단계에서 모든 참여자가 VOTE YES를 보내면 커밋을 지시(COMMIT)하고, 참여자들은 커밋 또는 롤백을 수행 후 완료 메시지(ACKNOWLEDGMENT)를 보낸다.[10]
Coordinator Cohort
QUERY TO COMMIT
- ------------------------------->
VOTE YES/NO prepare*/abort*
<-------------------------------
commit*/abort* COMMIT/ROLLBACK
- ------------------------------->
ACKNOWLEDGMENT commit*/abort*
<--------------------------------
end
`*` 표시는 레코드가 안정적인 스토리지로 강제됨을 뜻한다.[10]
5. 1. 성공 사례
모든 참여자가 커밋에 동의하는 경우, 다음과 같은 단계를 거쳐 트랜잭션이 성공적으로 처리된다.[10]1. 커밋 요청 단계: 코디네이터가 참여자들에게 쿼리를 커밋하도록 요청한다. (QUERY TO COMMIT)
2. 참여자들은 쿼리 실행 준비가 완료되면 VOTE YES를, 그렇지 않으면 VOTE NO를 코디네이터에게 보낸다. (VOTE YES/NO)
3. 커밋 단계: 코디네이터는 모든 참여자로부터 VOTE YES를 받으면, 참여자들에게 커밋을 수행하도록 지시한다. (COMMIT)
4. 참여자들은 커밋을 수행하고, 코디네이터에게 완료 메시지를 보낸다. (ACKNOWLEDGMENT)
5. 코디네이터는 모든 참여자로부터 완료 메시지를 받으면 트랜잭션을 종료한다. (end)
위 과정에서 `*` 표시는 레코드가 안정적인 스토리지에 기록됨을 의미한다.
5. 2. 실패 사례
참여자 중 하나라도 커밋에 실패하는 경우 트랜잭션은 롤백된다.[10]
5. 3. 시간 초과
5. 4. 오류 복구
[10]6. 단점
2단계 커밋 프로토콜의 가장 큰 단점은 블로킹 프로토콜이라는 점이다.
조정자가 영구적으로 실패하면 일부 참여자는 트랜잭션을 절대 해결하지 못한다. 참여자가 조정자로부터 커밋 요청 메시지에 대한 응답으로 동의 메시지를 보낸 후, 커밋 또는 롤백 메시지를 받을 때까지 블로킹된다.
2단계 커밋 프로토콜은 커밋 단계에서 조정자와 참여자 모두의 실패로부터 안정적으로 복구할 수 없다. 조정자만 실패하고 참여자가 커밋 메시지를 받지 못했다면 커밋이 발생하지 않았다고 안전하게 추론할 수 있다. 그러나 조정자와 참여자 모두 실패한 경우, 실패한 참여자가 처음으로 통지를 받았고 실제로 커밋을 했을 가능성이 있다. 새로운 조정자가 선택되더라도 모든 참여자로부터 동의를 받기 전까지는 작업을 자신 있게 진행할 수 없으므로 모든 참여자가 응답할 때까지 블로킹해야 한다.
2단계 커밋의 가장 큰 단점은 블록될 수 있다는 점이다. 메시지를 기다리는 상태에서는 노드는 블록되어 아무것도 할 수 없다. 따라서 어떤 리소스 잠금을 유지한 상태로 블록되어 있는 경우, 다른 프로세스가 해당 리소스를 획득하려 하면 그 프로세스도 블록된다. 또한, 어떤 노드는 다른 노드가 모두 장애 상태에 빠져도 계속 기다리게 된다. 조정자가 영구적인 장애 상태가 되면 각 참가자는 트랜잭션을 완료할 수 없게 된다. 그렇게 되면 관련 리소스도 잠긴 채로 남게 된다. 특히 참가자가 "합의" 메시지를 보내고, 조정자로부터 "커밋하라" 또는 "롤백하라"는 메시지가 오기를 기다리는 상태에서 그러한 블록 상태가 발생한다.
조정자가 "커밋해도 괜찮은가"라는 메시지를 참가자에게 보냈을 때, 모든 참가자가 응답할 때까지 조정자는 블록된다. 어떤 참가자가 영구적으로 장애 상태가 된 경우, 조정자는 영구적으로 블록된 채로 남게 된다. 이러한 경우 타임아웃이 발생하고, 조정자는 롤백하기로 결정한다. 이러한 보수적인 동작도 2단계 커밋의 불리한 점이다.
데이터베이스 연구에서는, 2단계 커밋의 비용을 최대한 증가시키지 않고 개선하려 해왔다.
7. 구현 및 최적화
데이터베이스 연구에서는 프로토콜 최적화[1][2][3] 및 특정 시스템의 동작 가정을 통해 2단계 커밋 프로토콜의 대부분의 이점을 유지하면서 비용을 줄이는 방법에 대해 연구가 진행되어 왔다.
추정 중단(Presumed Abort) 또는 추정 커밋(Presumed Commit)은 일반적인 최적화 방법이다.[2][3][5] 트랜잭션 결과(커밋 또는 중단)에 대한 가정을 통해 2단계 커밋 프로토콜 실행 중 참여자들의 메시지 및 로깅 작업을 절약할 수 있다. 예를 들어, 추정 중단의 경우, 시스템 실패 복구 중 복구 절차에서 특정 트랜잭션의 커밋에 대한 기록된 증거가 발견되지 않으면 해당 트랜잭션이 중단된 것으로 가정한다. 이는 중단이 전혀 기록되지 않아도 됨을 의미하며, 이러한 로깅은 생략될 수 있다. 일반적으로 실패 복구 중 최적화 유형에 따라 추가 작업에 대한 페널티가 발생하므로, 최적의 변형은 실패 및 트랜잭션 결과 통계에 따라 선택된다.
분산 시스템에서의 2단계 커밋의 전형적인 개선책으로 '''트리 구조 2단계 커밋'''(Tree 2 Phase Commit, 중첩 2PC 또는 재귀 2PC라고도 함)이 있다. 조정자는 통신의 트리 구조의 꼭대기(루트)가 되며, 참가자는 해당 트리 구조상의 다른 노드가 된다. 조정자로부터의 메시지는 트리 구조를 따라 전파되어 가고, 중간 노드에 해당하는 참가자는 하위 참가자의 응답을 모아 상위로 전달한다. 단, "중단" 메시지는 하위의 모든 응답을 기다리는 것이 아니라, 즉시 상위로 전송된다.
'''동적 2단계 커밋'''(Dynamic 2 Phase Commit, D2PC)[2][6]은 조정자를 미리 정해두지 않는 트리 구조 2단계 커밋이다. 가장 하위 노드(잎)는 트랜잭션이 완료되었을 때 "합의" 메시지를 상위로 보내고, 조정자는 선착순으로 동적으로 결정된다. 동적 2단계 커밋은 빠르며, 최소 시간으로 커밋을 완료할 수 있다.
7. 1. 일반적인 아키텍처
대부분 2단계 커밋 프로토콜은 컴퓨터 네트워크에 분산되어 있다. 이는 트랜잭션 관리자(TM, 2단계 커밋 에이전트 또는 트랜잭션 처리 모니터라고도 함)를 구현하여 쉽게 분산할 수 있으며, 각 트랜잭션에 대해 프로토콜을 실행한다(예: 더 오픈 그룹의 X/Open XA). 분산 트랜잭션에 관련된 데이터베이스, 참여자, 코디네이터는 모두 2단계 커밋을 사용하여 해당 트랜잭션을 종료하기 위해 TM(일반적으로 참여자와 동일한 네트워크 노드에 존재)을 등록한다. 각 분산 트랜잭션은 임시 TM 집합, 즉 트랜잭션 참여자가 등록하는 TM을 갖는다. 리더, 즉 코디네이터 TM은 각 트랜잭션에 대해 2단계 커밋을 조정하며, 일반적으로 코디네이터 데이터베이스의 TM이다. 그러나 성능 또는 신뢰성상의 이유로 코디네이터 역할은 다른 TM으로 이전될 수 있다. 참여자는 서로 2단계 커밋 메시지를 교환하는 대신, 각 TM과 메시지를 교환한다. 관련 TM은 해당 트랜잭션을 종료하기 위해 각 참여자를 "대표"하여 2단계 커밋 프로토콜 스키마를 실행하기 위해 서로 통신한다. 이 아키텍처를 통해 프로토콜은 완전히 분산되고(중앙 처리 구성 요소 또는 데이터 구조가 필요 없음) 네트워크 노드 수(네트워크 크기)에 따라 효과적으로 확장된다.이러한 일반적인 아키텍처는 투표 메커니즘과 프로토콜 참여자에 대한 결과 전파를 사용하기 때문에 2단계 커밋 외에 다른 원자적 커밋 프로토콜의 분배에도 효과적이다.
7. 2. 프로토콜 최적화
데이터베이스 연구는 프로토콜 최적화[1][2][3] 및 특정 시스템의 동작 가정을 통해 2단계 커밋 프로토콜의 대부분의 이점을 유지하면서 비용을 줄이는 방법에 대해 진행되어 왔다.추정 중단(Presumed Abort) 또는 추정 커밋(Presumed Commit)은 이러한 일반적인 최적화 방법이다.[2][3][5] 트랜잭션 결과(커밋 또는 중단)에 대한 가정을 통해 2단계 커밋 프로토콜 실행 중 참여자들의 메시지 및 로깅 작업을 절약할 수 있다. 예를 들어, 추정 중단의 경우, 시스템 실패 복구 중 복구 절차에서 특정 트랜잭션의 커밋에 대한 기록된 증거가 발견되지 않으면 해당 트랜잭션이 중단된 것으로 가정한다. 이는 중단이 전혀 기록되지 않아도 됨을 의미하며, 이러한 로깅은 생략될 수 있다. 일반적으로 실패 복구 중 최적화 유형에 따라 추가 작업에 대한 페널티가 발생하므로, 최적의 변형은 실패 및 트랜잭션 결과 통계에 따라 선택된다.
트리 2PC 프로토콜[2] (중첩 2PC 또는 재귀 2PC라고도 함)는 컴퓨터 네트워크에서 2PC의 일반적인 변형으로, 기본 통신 인프라를 더 잘 활용한다. 분산 트랜잭션의 참여자는 일반적으로 트리 구조, 즉 호출 트리(참여자가 노드이고 에지가 호출(통신 링크)인 트리)를 정의하는 순서로 호출된다. 동일한 트리는 일반적으로 2PC 프로토콜에 의해 트랜잭션을 완료하는 데 사용되지만, 원칙적으로 다른 통신 트리도 이를 위해 사용할 수 있다. 트리 2PC에서 코디네이터는 통신 트리의 루트("상단")(역트리)로 간주되는 반면, 참여자는 다른 노드이다. 코디네이터는 트랜잭션을 시작한 노드(다른 참여자를 재귀적으로(전이적으로) 호출)일 수 있지만, 동일한 트리 내의 다른 노드가 대신 코디네이터 역할을 할 수도 있다. 코디네이터로부터의 2PC 메시지는 트리를 따라 "아래로" 전파되는 반면, 코디네이터로의 메시지는 하위의 모든 참여자로부터 참여자에 의해 "수집"된 후 적절한 메시지를 트리를 따라 "위로" 보낸다(중단 메시지는 수신 즉시 또는 현재 참여자가 중단을 시작하는 경우 "위로" 전파됨).
동적 2단계 커밋(D2PC, Dynamic two-phase commit) 프로토콜[2][6]은 사전 결정된 코디네이터가 없는 트리 2PC의 변형이다. 이 프로토콜은 이전에 제안된 여러 최적화를 포함한다. 동의 메시지(예: 투표)는 모든 리프에서 시작하여, 각 리프가 트랜잭션을 대신하여 작업을 완료할 때(준비 상태가 됨) 전파된다. 중간 노드(리프가 아닌 노드)는 동의 메시지가 아직 수신되지 않은 마지막(단일) 인접 노드로 동의 메시지를 보낼 때 준비 상태를 보낸다. 코디네이터는 트랜잭션 트리에서 충돌하는 동의 메시지를 경합하여 동적으로 결정된다. 이러한 충돌은 코디네이터가 될 트랜잭션 트리 노드에서 발생하거나 트리 에지에서 발생한다. 후자의 경우 두 에지의 노드 중 하나가 코디네이터로 선택된다(임의의 노드). D2PC는 시간 최적이다(특정 트랜잭션 트리의 모든 인스턴스 및 특정 트리 2PC 프로토콜 구현 중에서; 모든 인스턴스는 동일한 트리를 가짐; 각 인스턴스는 다른 노드를 코디네이터로 가짐). 최적의 코디네이터를 선택함으로써 D2PC는 코디네이터와 각 참여자를 가능한 최소 시간 내에 커밋하여 각 트랜잭션 참여자(트리 노드)에서 잠긴 자원을 가능한 가장 빨리 해제할 수 있도록 한다.
분산 시스템에서의 2단계 커밋의 전형적인 개선책으로 '''트리 구조 2단계 커밋'''(Tree 2 Phase Commit)이 있다. 조정자는 통신의 트리 구조의 꼭대기(루트)가 되며, 참가자는 해당 트리 구조상의 다른 노드가 된다. 조정자로부터의 메시지는 트리 구조를 따라 전파되어 가고, 중간 노드에 해당하는 참가자는 하위 참가자의 응답을 모아 상위로 전달한다. 단, "중단" 메시지는 하위의 모든 응답을 기다리는 것이 아니라, 즉시 상위로 전송된다.
'''동적 2단계 커밋'''(Dynamic 2 Phase Commit)은 조정자를 미리 정해두지 않는 트리 구조 2단계 커밋이다. 가장 하위 노드(잎)는 트랜잭션이 완료되었을 때 "합의" 메시지를 상위로 보내고, 조정자는 선착순으로 동적으로 결정된다. 동적 2단계 커밋은 빠르며, 최소 시간으로 커밋을 완료할 수 있다.
참조
[1]
서적
Concurrency Control and Recovery in Database Systems
http://research.micr[...]
Addison Wesley Publishing Company
[2]
서적
Transactional Information Systems
http://www.elsevier.[...]
Elsevier
[3]
서적
Principles of Transaction Processing, 2nd Edition
http://www.elsevierd[...]
Morgan Kaufmann (Elsevier)
[4]
논문
Transaction management in the R* distributed database management system
http://dl.acm.org/ci[...]
1986-12
[5]
논문
Efficient commit protocols for the tree of processes model of distributed transactions
http://portal.acm.or[...]
1985-04
[6]
논문
The Dynamic Two Phase Commitment (D2PC) protocol
Springer
[7]
서적
Concurrency Control and Recovery in Database Systems
http://research.micr[...]
Addison Wesley Publishing Company
[8]
서적
Transactional Information Systems
http://www.elsevier.[...]
Elsevier
[9]
서적
Principles of Transaction Processing, 2nd Edition
http://www.elsevierd[...]
Morgan Kaufmann (Elsevier)
[10]
논문
Transaction management in the R* distributed database management system
http://dl.acm.org/ci[...]
1986-12
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com