[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,160 @@
|
||||
---
|
||||
id: optimistic-concurrency-control
|
||||
title: 낙관적 동시성 제어 (Optimistic Concurrency Control)
|
||||
category: Coding
|
||||
status: draft
|
||||
canonical_id: optimistic-concurrency-control
|
||||
aliases: [OCC, optimistic locking, version field, ETag, 낙관적 락]
|
||||
duplicate_of: null
|
||||
source_trust_level: B
|
||||
confidence_score: 0.9
|
||||
verification_status: conceptual
|
||||
created_at: 2026-05-09
|
||||
updated_at: 2026-05-09
|
||||
last_reinforced: 2026-05-09
|
||||
review_reason: ""
|
||||
merge_history: []
|
||||
tags: [coding, concurrency, database, http, vibe-coding]
|
||||
raw_sources: ["P-Reinforce session 2026-05-09 — bulk Coding seed batch 1"]
|
||||
tech_stack:
|
||||
language: "SQL / TypeScript / HTTP"
|
||||
applicable_to: ["Backend", "REST API", "DB write paths"]
|
||||
applied_in: []
|
||||
---
|
||||
|
||||
# 낙관적 동시성 제어
|
||||
|
||||
> 충돌은 드물다고 가정하고 락 없이 진행. 충돌이 발생하면 **버전 비교로 감지하고 재시도하거나 사용자에게 알린다**. 비관적 락보다 throughput 높지만 충돌이 잦으면 retry 폭주.
|
||||
|
||||
## 📖 핵심 개념
|
||||
|
||||
두 사용자가 같은 레코드를 동시에 수정할 때:
|
||||
- **비관적(pessimistic) 락**: 한 명이 잠금 → 다른 명은 대기. throughput 낮음, deadlock 위험.
|
||||
- **낙관적(optimistic)**: 둘 다 진행, 마지막 commit 시점에 "내가 읽은 버전이 아직도 유효한가?" 확인. 깨졌으면 reject.
|
||||
|
||||
낙관적 락은 다음 둘 중 하나로 구현:
|
||||
1. **Version 컬럼** (정수 또는 timestamp): UPDATE 시 `WHERE version = ?` 조건. 변경 시 version+1.
|
||||
2. **HTTP ETag / If-Match**: 서버가 ETag 발급 → 클라이언트가 PUT 시 `If-Match` 헤더로 보냄.
|
||||
|
||||
## 💻 코드 패턴
|
||||
|
||||
### 1. Version 컬럼 (SQL)
|
||||
|
||||
```sql
|
||||
ALTER TABLE orders ADD COLUMN version INT NOT NULL DEFAULT 0;
|
||||
```
|
||||
|
||||
```ts
|
||||
async function updateShipping(orderId: string, addr: Address, expectedVersion: number) {
|
||||
const result = await db.query(
|
||||
`UPDATE orders
|
||||
SET shipping = $1, version = version + 1
|
||||
WHERE id = $2 AND version = $3`,
|
||||
[addr, orderId, expectedVersion]
|
||||
);
|
||||
|
||||
if (result.rowCount === 0) {
|
||||
// 누군가 이미 수정했거나 주문이 없음
|
||||
throw new ConflictError('Concurrent update detected — re-read and try again');
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. HTTP ETag
|
||||
|
||||
```ts
|
||||
// GET — ETag 발급
|
||||
app.get('/api/orders/:id', async (req, res) => {
|
||||
const order = await db.findOrder(req.params.id);
|
||||
res.setHeader('ETag', `"${order.version}"`);
|
||||
res.json(order);
|
||||
});
|
||||
|
||||
// PUT — If-Match 검증
|
||||
app.put('/api/orders/:id', async (req, res) => {
|
||||
const ifMatch = req.header('If-Match');
|
||||
if (!ifMatch) return res.status(428).json({ error: 'If-Match required' });
|
||||
|
||||
const expected = parseInt(ifMatch.replace(/"/g, ''), 10);
|
||||
try {
|
||||
await updateShipping(req.params.id, req.body.shipping, expected);
|
||||
res.status(204).end();
|
||||
} catch (e) {
|
||||
if (e instanceof ConflictError) return res.status(412).json({ error: 'Version mismatch' });
|
||||
throw e;
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
### 3. 자동 재시도 wrapper
|
||||
|
||||
```ts
|
||||
async function retryOnConflict<T>(
|
||||
op: () => Promise<T>,
|
||||
{ maxAttempts = 3, backoffMs = 50 }: { maxAttempts?: number; backoffMs?: number } = {}
|
||||
): Promise<T> {
|
||||
let lastErr: unknown;
|
||||
for (let i = 0; i < maxAttempts; i++) {
|
||||
try {
|
||||
return await op();
|
||||
} catch (e) {
|
||||
if (!(e instanceof ConflictError)) throw e;
|
||||
lastErr = e;
|
||||
await new Promise(r => setTimeout(r, backoffMs * Math.pow(2, i)));
|
||||
}
|
||||
}
|
||||
throw lastErr;
|
||||
}
|
||||
```
|
||||
|
||||
`op()` 안에서 항상 **다시 read → 변경 → write** 흐름이어야 한다. 같은 expectedVersion 으로 재시도하면 영원히 실패.
|
||||
|
||||
### 4. Document DB (MongoDB) — findOneAndUpdate with filter
|
||||
|
||||
```ts
|
||||
const result = await orders.findOneAndUpdate(
|
||||
{ _id: orderId, version: expectedVersion },
|
||||
{ $set: { shipping: addr }, $inc: { version: 1 } },
|
||||
{ returnDocument: 'after' }
|
||||
);
|
||||
if (!result.value) throw new ConflictError('version mismatch');
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준
|
||||
|
||||
| 상황 | OCC 적합 | 비관적 락 적합 |
|
||||
|---|---|---|
|
||||
| 충돌 빈도 < 5% | ✅ | ❌ |
|
||||
| 충돌 빈도 > 30% | ❌ (retry 폭주) | ✅ |
|
||||
| 트랜잭션이 짧음 | ✅ | — |
|
||||
| 트랜잭션이 길고 사용자 대기 중 | ✅ (사용자에게 충돌 알림) | ❌ (deadlock) |
|
||||
| 분산 환경 (DB 여러 대) | ✅ | 어려움 |
|
||||
| 잔액 / 재고 같은 strict invariant | OCC 가능하지만 SELECT FOR UPDATE 또는 `UPDATE ... WHERE balance >= ?` 사용 | ✅ |
|
||||
|
||||
## ❌ 안티패턴
|
||||
|
||||
- **버전 비교 없이 `UPDATE SET ... WHERE id = ?`**: lost update. 마지막 쓰기가 이전 쓰기를 조용히 덮어씀.
|
||||
- **클라이언트가 보낸 version 을 그대로 신뢰 후 검증 안 함**: 클라이언트가 의도적으로 옛 version 보내면 항상 통과.
|
||||
- **재시도 시 같은 expectedVersion 사용**: 영원히 실패. 재시도 안에서 **다시 read** 해야 함.
|
||||
- **충돌 시 묵묵히 무시**: 사용자는 자기 변경이 적용되었다고 믿음. 실제로 사라짐. 명시적 4xx 응답 + UI 알림.
|
||||
- **Version 을 timestamp 로**: 같은 ms 에 두 update 가 들어오면 둘 다 통과. 정수 시퀀스가 안전.
|
||||
- **모든 곳에 자동 retry**: 사용자가 form 에 입력한 값을 자동 재시도 = 사용자가 본 데이터와 다를 수 있음. UI 가 "다른 사람이 수정했어요. 다시 보시겠어요?" 묻기.
|
||||
- **OCC 와 application-level 캐시 결합**: 캐시가 stale version 을 들고 있으면 영원히 충돌. 캐시 invalidation 정책 필수.
|
||||
|
||||
## 🤖 LLM 활용 힌트
|
||||
|
||||
- LLM에게 SQL UPDATE 작성: "**WHERE 조건에 version = expected 추가, rowCount 0 이면 ConflictError throw**" 명시.
|
||||
- REST API: "**GET 응답에 ETag, PUT 요청에 If-Match 강제 (없으면 428)**" 패턴 요청.
|
||||
- retry wrapper: "**read → modify → write 흐름이어야 retry 의미 있음. 같은 expected 로 재시도 금지**" 강조.
|
||||
|
||||
## 🧪 검증 상태
|
||||
|
||||
- verification_status: `conceptual`
|
||||
- JPA `@Version`, Hibernate optimistic locking, REST API ETag 표준 (RFC 7232) 의 핵심 패턴.
|
||||
- 적용 사례 발견 시 `applied_in` 추가.
|
||||
|
||||
## 🔗 관련 문서
|
||||
|
||||
- [[Idempotent_Operations]]
|
||||
- [[Backpressure_Patterns]]
|
||||
- [[Error_Handling_Result_vs_Throw]]
|
||||
Reference in New Issue
Block a user