여러 연산을 하나의 단위로
안전하게 묶는 법 — 트랜잭션

정의 (Definition)

트랜잭션
(Transaction)

여러 data item에 접근하고 갱신하는 하나의 프로그램 실행 단위(a unit of program execution).

트랜잭션이 다뤄야 할 두 가지 핵심 문제:

• Failures — 하드웨어 고장·시스템 충돌 등 장애.
• Concurrent execution — 여러 트랜잭션의 동시 실행.

예제: Fund Transfer (A → B, $50)

// T_i: A 계좌에서 B 계좌로 $50 이체
read(A);
A := A - 50;
write(A);
read(B);
B := B + 50;
write(B);

이 6개 연산은 "전부 반영되거나 전혀 반영되지 않아야" 하며, 도중에 A+B 합이 깨져 보여서도 안 된다.

A Atomicity

All or Nothing. 트랜잭션의 모든 연산이 DB에 반영되거나, 전혀 반영되지 않거나 둘 중 하나다.

C Consistency

고립 실행(in isolation)되는 트랜잭션은 데이터베이스의 일관성을 보존한다.

I Isolation = Serializability

각 트랜잭션은 다른 동시 트랜잭션의 존재를 인지하지 못한다. 중간 결과(intermediate result)는 다른 트랜잭션에 숨겨진다.

D Durability

트랜잭션이 성공적으로 완료되면, 이후 시스템 장애가 발생해도 그 변경은 유지된다.

5개 상태

Active

초기 상태. 실행 중(executing)인 상태.

Partially
committed

마지막 명령(final statement)을 실행한 직후.

Failed

정상 진행이 불가능함을 발견한 후.

Aborted

롤백(rollback)을 마쳐 트랜잭션 이전 상태로 복원된 후 → 재시작(restart) 또는 폐기(kill).

Committed

성공적으로 완료(successful completion)된 후.

상태 전이 (Transitions)

• active → partially committed → committed (정상 경로)
• active → failed
• partially committed → failed
• failed → aborted

aborted 후에는 재시작하거나(restart) 그대로 종료(kill)한다.

정의 & 규칙

Schedule

동시 실행 트랜잭션들의 명령에 대한 시간순 실행 순서(chronological order).

• 모든 트랜잭션의 모든 명령을 포함해야 한다.
• 각 트랜잭션 내부의 명령 순서는 보존되어야 한다.
• 각 트랜잭션의 마지막 명령은 Commit(성공) 또는 Abort(실패).

예제 트랜잭션

T1

A에서 B로 $50 이체.

T2

A의 10%를 B로 이체.

• Schedule 1: T1 다음 T2 (serial)
• Schedule 2: T2 다음 T1 (serial)
• Schedule 3: 인터리빙이지만 Schedule 1과 equivalent → serializable
• Schedule 4: 인터리빙, A+B 보존 안 됨 → not serializable

Conflict Equivalent

스케줄 S를, 인접한 비충돌(non-conflicting) 명령들을 swap하는 연산만으로 S'로 변환할 수 있으면 S와 S'는 conflict equivalent하다.

Conflict Serializable

어떤 스케줄이 하나의 serial 스케줄과 conflict equivalent하면 그 스케줄은 conflict serializable하다.

작도 규칙 (Construction)

• 정점(vertex) = 각 트랜잭션.
• Tᵢ와 Tⱼ의 명령이 충돌하고 Tᵢ가 먼저 접근하면 간선 Tᵢ → Tⱼ를 그린다.
• 간선에 충돌한 항목(item)을 라벨로 붙일 수 있다.

판정 (Test)

• acyclic(비순환) ⟺ conflict serializable.
• acyclic이면 topological sort로 직렬화 순서(serializability order)를 얻는다 (여러 개 가능).
• cycle(순환)이 있으면 conflict serializable 아님. 예: T1↔T2 양방향 간선.

포함 관계 다이어그램

Recoverable

Tⱼ가 Tᵢ가 쓴 데이터를 읽었다면, Tᵢ의 commit이 Tⱼ의 commit보다 먼저 일어나는 스케줄.

Cascading Rollback

한 트랜잭션의 실패가 연쇄 롤백을 유발(T10 abort → T11, T12 롤백). recoverable하더라도 발생할 수 있어 바람직하지 않다.

Cascadeless

Tⱼ가 Tᵢ가 쓴 것을 읽으면 Tᵢ의 commit이 Tⱼ의 read보다 먼저. 모든 cascadeless ⊆ recoverable.

각 수준 메모

Serializable

기본 격리 수준(SQL92 / SQLite). 모든 이상 현상 방지.

Repeatable read

MySQL 기본. 같은 레코드 재읽기는 동일하나 phantom 여지.

Read committed

commit된 값만 읽음. 재읽기 값은 달라질 수 있음.

Read uncommitted

commit 안 된 값도 읽음(가장 약함).

SQL 설정

-- 트랜잭션 종료
COMMIT WORK;
ROLLBACK WORK;

-- 격리 수준 설정
SET TRANSACTION ISOLATION LEVEL
     SERIALIZABLE;

JDBC에서 auto-commit 해제: setAutocommit(false). 이후 명시적 commit/rollback 필요.

1단계 · 충돌 작도

• W₁(A) · R₂(A) → W-R 충돌, T1 먼저 ⇒ T1 → T2
• W₂(B) · R₃(B) → W-R 충돌, T2 먼저 ⇒ T2 → T3
• Q는 T3만 접근 → 간선 없음

2단계 · cycle 판정

간선은 T1 → T2 → T3 뿐. 되돌아오는 간선이 없으므로 acyclic. ⇒ conflict serializable 확정.

3단계 · 위상 정렬

선형 사슬이므로 직렬화 순서는 T1 ; T2 ; T3 하나로 유일하다. (간선이 더 적었다면 여러 순서가 가능 — 아래 콜아웃 참고.)

blind write와 조합 폭발

conflict serializability는 선행 그래프 acyclic 검사로 다항 시간에 끝난다. 그러나 view serializability는 blind write(읽지 않고 바로 write) 때문에 final-write 조건을 만족시킬 후보 직렬 순서가 폭발적으로 늘어난다.

read-from / final-write 제약을 모두 만족하는 트랜잭션 순서를 찾는 문제는 polygraph(방향이 미확정인 간선 쌍 중 하나를 고르는 그래프)의 acyclic 방향 배정 문제로 환원되며, 이는 NP-complete로 알려져 있다.

축 1 · 직렬가능성 (정확성)

Serial ⊊ Conflict-serializable ⊊ View-serializable ⊊ (모든 serializable 스케줄).

축 2 · 복구가능성 (장애 복구)

Strict ⊊ Cascadeless ⊊ Recoverable ⊊ (모든 스케줄). 다음 절에서 상세히.

1 Recoverable (가장 약함)

Tⱼ가 Tᵢ가 쓴 데이터를 읽었다면, Tᵢ의 commit이 Tⱼ의 commit보다 먼저.

// recoverable (단, cascade 발생)
T8: W(A)
T9: R(A)        // 미커밋 값 읽음
T8: commit
T9: commit     // T8 이후 → OK

2 Cascadeless (연쇄롤백 없음)

Tⱼ는 Tᵢ가 commit한 뒤에만 Tᵢ가 쓴 값을 읽는다(Tᵢ commit이 Tⱼ read보다 먼저). 미커밋 값을 절대 안 읽으므로 연쇄 롤백 불가능.

// cascadeless
T8: W(A)
T8: commit
T9: R(A)        // 커밋된 값만 읽음
T9: commit

3 Strict (가장 강함)

Tᵢ가 쓴 데이터 항목은 Tᵢ가 commit/abort할 때까지 다른 TX가 read도 write도 못함. 미커밋 데이터에 대한 모든 접근을 차단한다.

// strict: W(A) 후 T8 종료까지
// 다른 TX는 A를 R/W 불가
T8: W(A)
T8: commit   // 이제부터 A 접근 허용
T9: R(A) / W(A)

왜 DBMS는 strict를 선호하는가

• 복구가 단순하다. abort 시 그 TX가 쓴 값은 아무도 보지 못했으므로, before-image(이전 값)로 즉시 undo하면 끝 — 다른 TX 갱신을 추적·연쇄 롤백할 필요가 없다.
• cascade 없음. cascadeless가 보장되므로 한 TX 실패가 다른 TX 롤백을 유발하지 않는다.
• before-image 덮어쓰기 안전. 미커밋 write는 다른 TX가 안 읽으므로, 로그 기반 undo가 항상 올바른 복원값을 갖는다.
• 대가: 항목을 commit까지 잠가 두므로 동시성은 다소 낮아진다. 대부분 상용 DBMS는 strict 2PL로 이 성질을 얻는다(Ch18).

Dirty Read (미커밋 값 읽기)

T1: W(X)      // X=100→200 (미커밋)
T2: R(X)      // 200을 읽음 (dirty)
T1: abort   // X 200은 존재한 적 없음
T2: ... 200 기반 결정 → 오염

Read committed 이상에서 차단.

Non-repeatable Read (재읽기 불일치)

T1: R(X)      // X=100
T2: W(X), commit   // X=150
T1: R(X)      // 같은 행, 150 (달라짐!)

같은 point query 두 번 결과 상이. Repeatable read 이상에서 차단.

Phantom Read (유령 행)

T1: SELECT count(*) WHERE age>30  // 5
T2: INSERT (age=40), commit
T1: SELECT count(*) WHERE age>30  // 6!

같은 range query에 새 행 등장. tuple-lock으로 미삽입 행은 못 잠근다. Serializable(또는 범위 잠금)에서 차단.

Serialization Anomaly

// 각각은 commit됐지만 어떤
// 직렬 순서와도 결과 불일치
T1: R(A), W(B)
T2: R(B), W(A)
// T1→T2도 T2→T1도 결과와 안 맞음

선행 그래프에 cycle(T1↔T2). Serializable에서만 차단.

Snapshot Isolation (SI) — forward reference

각 트랜잭션이 시작 시점의 일관된 스냅샷을 읽고, write는 자신의 버전에만 한다(MVCC). 읽기는 쓰기를 막지 않아 동시성이 높고, dirty/non-repeatable/phantom read를 대부분 막는다.

⤳ 자세한 메커니즘(버전·가시성·first-committer-wins)은 Ch18 동시성 제어에서 다룬다.