2nd/10_Wiki/Topics/Domain_Programming/Coding/DB_Transaction_Isolation.md

id, title, category, status, source_trust_level, verification_status, created_at, updated_at, tags, tech_stack, applied_in, aliases

id	title	category	status	source_trust_level	verification_status	created_at	updated_at	tags	tech_stack	applied_in	aliases
db-transaction-isolation	DB Transaction Isolation Levels — 실전 선택	Coding	draft	B	conceptual	2026-05-09	2026-05-09	database transaction isolation postgres vibe-coding	language applicable_to SQL / Postgres Backend		SERIALIZABLE REPEATABLE READ READ COMMITTED phantom read

DB Transaction Isolation

Postgres default = READ COMMITTED. 충분한 경우 많지만 race 가 진짜로 위험한 곳에는 SERIALIZABLE + retry. 무지성 SERIALIZABLE 은 throughput 폭락.

📖 핵심 개념

4 단계 (SQL standard):

• READ UNCOMMITTED: dirty read 허용 (Postgres 는 실제로 READ COMMITTED 처럼 동작).
• READ COMMITTED: 디폴트. 같은 트랜잭션 안에서 다른 SELECT 가 다른 결과 가능 (non-repeatable).
• REPEATABLE READ (Postgres = snapshot): 트랜잭션 시작 시점 snapshot. 같은 SELECT = 같은 결과.
• SERIALIZABLE: 직렬 실행한 것과 같은 결과 보장. 충돌 시 SerializationFailure throw.

💻 코드 패턴

명시적 isolation

BEGIN ISOLATION LEVEL SERIALIZABLE;
-- ...
COMMIT;

Node + pg

await client.query('BEGIN ISOLATION LEVEL SERIALIZABLE');
try {
  // ... business logic ...
  await client.query('COMMIT');
} catch (e: any) {
  await client.query('ROLLBACK');
  if (e.code === '40001') {  // serialization_failure
    // 재시도 가능
  }
  throw e;
}

Race condition 예시 — 잔액 차감

-- ❌ READ COMMITTED 에서 race
BEGIN;
SELECT balance FROM accounts WHERE id = 1;  -- 100
-- 다른 트랜잭션이 동시 동일 작업 진행
UPDATE accounts SET balance = balance - 50 WHERE id = 1;  -- 50
COMMIT;
-- 두 트랜잭션 모두 50 으로 끝나는 게 아니라 0 으로 끝남 (UPDATE 의 expression 은 안전)
-- BUT: 절차상 잔액 < 50 검사를 SELECT 후 했다면 둘 다 통과 → 음수 가능

해결 방법 4가지:

-- 1) 단일 UPDATE 에서 검사 + 차감 (가장 단순)
UPDATE accounts SET balance = balance - 50
  WHERE id = 1 AND balance >= 50
  RETURNING balance;
-- rowCount = 0 → 잔액 부족

-- 2) SELECT FOR UPDATE — 잠금
BEGIN;
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE; -- 다른 tx 블록
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
COMMIT;

-- 3) SERIALIZABLE — 직렬 보장
BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT balance FROM accounts WHERE id = 1;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
COMMIT;
-- 충돌 시 SerializationFailure → app 에서 재시도

-- 4) Optimistic — version
UPDATE accounts SET balance = balance - 50, version = version + 1
  WHERE id = 1 AND version = $expected;

🤔 의사결정 기준

상황	권장
일반 CRUD	READ COMMITTED (default)
복잡 read-write 한 트랜잭션 안에서 일관성 필요	REPEATABLE READ
잔액 / 재고 / 좌석 예약 (strict)	SERIALIZABLE + retry, OR 단일 UPDATE 표현식
Read-only report (스냅샷 일관)	REPEATABLE READ
단순 검사+수정	UPDATE ... WHERE 조건 한 줄로

❌ 안티패턴

• 모든 곳 SERIALIZABLE: throughput 폭락. 정말 필요한 곳만.
• SERIALIZABLE 인데 retry 없음: SerializationFailure 에 사용자 에러 노출.
• 트랜잭션 안에서 외부 API 호출: 트랜잭션 길어짐 → lock contention.
• lock 순서 일관성 없음: deadlock. 항상 같은 순서로 row 잠금 (보통 ID ASC).
• 트랜잭션 너무 큼 (수천 row 변경): 다른 트랜잭션 blocking. 작은 batch.
• autocommit 끄고 commit 잊음: 영구 lock + 메모리 leak. 명시적 commit/rollback.
• READ UNCOMMITTED 가정: Postgres 에서 동작 다름. 디폴트 READ COMMITTED 가정.

🤖 LLM 활용 힌트

• "단일 row 검사+수정은 한 UPDATE 표현식. 여러 row 일관성 필요면 SERIALIZABLE + retry" 명시.
• 트랜잭션 안에서 외부 호출 금지 강제.

🔗 관련 문서

• Optimistic_Concurrency_Control
• DB_Connection_Pool