트랜잭션 격리 수준과 이상 현상

지도이 토론의 길

동시 트랜잭션이 만드는 문제 → 이상 현상 3종 → 격리 수준이 무엇을 막나 → 내부 구현(MVCC) → 강한 격리의 함정과 비용 → 실무 결정.

출연토론자

1왜 격리가 필요한가 — 동시성이라는 압력

2문제 재현 — 이상 현상 3종 시뮬레이터

두 트랜잭션 T1·T2가 같은 데이터를 동시에 건드릴 때 무슨 일이 나는지 직접 단계 진행해 보자. 시나리오를 고르고 다음 단계를 눌러 인터리빙을 재생한다.

3현상 해부 — 셋은 어떻게 다른가

4해결 — 격리 수준이 무엇을 막나 (다이얼을 돌려보자)

슬라이더로 격리 수준을 올리면 어떤 이상 현상이 차단되는지 표가 갱신된다. 위로 갈수록 안전하지만 동시성은 줄어든다.

5내부 동작 — MVCC는 어떻게 락 없이 읽기를 격리하나

아래는 한 행(balance)의 버전 체인. 슬라이더로 "읽는 트랜잭션의 스냅샷 시점"을 바꾸면, 그 시점에 보이는 버전이 초록으로 강조된다.

6강한 격리의 함정 — Snapshot Isolation은 직렬화가 아니다

6.5직접 보기 — Write Skew (on-call 의사)

두 트랜잭션이 각자 스냅샷에서 "on-call 2명"을 확인하고 자기를 뺀다. 격리 수준을 바꿔 결과를 비교하라.

7종합 트레이드오프

8의사결정 가이드

9코드로 보기

① lost update를 막는 두 방법

-- 비관적 락: 읽을 때 행을 잠근다 (RC에서도 안전)
BEGIN;
SELECT balance FROM account WHERE id = 42 FOR UPDATE;  -- 다른 tx는 여기서 대기
UPDATE account SET balance = balance - 100 WHERE id = 42;
COMMIT;

-- 낙관적 락: 버전 컬럼으로 충돌을 감지, 충돌 시 재시도
UPDATE account SET balance = 900, version = version + 1
WHERE id = 42 AND version = 7;  -- 영향받은 행 0이면 누가 먼저 바꾼 것 → 재시도

② SERIALIZABLE 재시도 패턴 (의사 코드)

for attempt in 1..MAX:
    try:
        tx.begin(isolation="SERIALIZABLE")
        # ... read-modify-write with invariant check ...
        tx.commit()
        break
    except SerializationFailure:   # SQLSTATE 40001
        tx.rollback()
        sleep(backoff(attempt))    # 지수 백오프 후 재시도

+더 파고들 키워드