Antigravity Agent
122 lines
4.1 KiB
Markdown
122 lines
4.1 KiB
Markdown
---
|
|
id: db-transaction-isolation
|
|
title: DB Transaction Isolation Levels — 실전 선택
|
|
category: Coding
|
|
status: draft
|
|
source_trust_level: B
|
|
verification_status: conceptual
|
|
created_at: 2026-05-09
|
|
updated_at: 2026-05-09
|
|
tags: [database, transaction, isolation, postgres, vibe-coding]
|
|
tech_stack: { language: "SQL / Postgres", applicable_to: ["Backend"] }
|
|
applied_in: []
|
|
aliases: [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
|
|
```sql
|
|
BEGIN ISOLATION LEVEL SERIALIZABLE;
|
|
-- ...
|
|
COMMIT;
|
|
```
|
|
|
|
### Node + pg
|
|
```ts
|
|
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 예시 — 잔액 차감
|
|
|
|
```sql
|
|
-- ❌ 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가지:
|
|
|
|
```sql
|
|
-- 1) 단일 UPDATE 에서 검사 + 차감 (가장 단순)
|
|
UPDATE accounts SET balance = balance - 50
|
|
WHERE id = 1 AND balance >= 50
|
|
RETURNING balance;
|
|
-- rowCount = 0 → 잔액 부족
|
|
```
|
|
|
|
```sql
|
|
-- 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;
|
|
```
|
|
|
|
```sql
|
|
-- 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 에서 재시도
|
|
```
|
|
|
|
```sql
|
|
-- 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]]
|