낙관적 병행제어
IT위키
더 많은 작업
- Optimistic Concurrency Control
- 트랜잭션 수행 동안은 어떠한 검사도 하지 않고, 트랜잭션 종료 시에 일괄적으로 검사하는 데이터베이스 병행제어 기법
- 트랜잭션 수행 동안 그 트랜잭션을 위해 유지되는 데이터 항목들의 지역 사본에 대해서만 갱신
- 트랜잭션 종료 시에 동시성을 위한 트랜잭션 직렬화가 검증되면 일시에 DB로 반영
- 장기 트랜잭션 철회시 자원낭비 가능성이 있어, 동시 사용 빈도가 낮은 시스템에서 주로 사용
| 과정 | 동작 |
|---|---|
| Read Phase | 검증 없이 트랜잭션 수행 |
| Validation Phase | 종료 시 동시성 검증 수행 |
| Execution Phase | 문제 없을 시 기록, 동시성 문제 발견 시 철회 |
- Pessimistic Concurrency Control
- '낙관적 병행제어'란 충돌이 있을 것을 가정한 기존 로킹 방식에 대한 다른 접근
- 기존의 로킹 방식 등은 '비관적 병행제어'로 분류 가능(해당 용어는 잘 사용하지 않음)
응용 프로그램 수준에서는 같은 생각을 낙관적 로킹과 비관적 로킹이라 부른다. 비관적 로킹은 데이터를 읽을 때부터 행에 로크를 걸어 작업이 끝날 때까지 다른 사용자의 변경을 막는다. 낙관적 로킹은 읽을 때 로크를 걸지 않고, 갱신하는 시점에 그 사이 다른 사용자가 행을 바꿨는지(버전 번호·타임스탬프·원래 값 비교) 확인해 충돌이면 거부하고 다시 하게 한다.[1][2]
| 구분 | 낙관적 로킹 | 비관적 로킹 |
|---|---|---|
| 로크 시점 | 작업을 마치고 반영(갱신·커밋)할 때만 | 읽을 때부터 작업이 끝날 때까지 |
| 로크 보유 시간 | 매우 짧다 | 사용자가 작업하는 동안 내내 |
| 충돌 처리 | 반영 시점에 충돌을 발견하면 거부·재시도 | 처음부터 막아서 충돌이 생기지 않는다 |
| 알맞은 환경 | 충돌이 드물고, 사용자가 오래 머물거나 작업을 중단할 수 있는 환경(웹·인터넷 응용) | 같은 행에 갱신이 몰려 충돌이 잦고 로크 시간이 짧은 일괄 처리 |
- 인터넷 응용에서는 사용자가 화면을 띄워 놓고 자리를 비우거나 트랜잭션 중간에 떠나는 일이 흔하다. 비관적 로킹을 쓰면 그동안 로크가 풀리지 않아 다른 사용자가 계속 기다리므로, 이런 환경에는 낙관적 로킹이 더 효율적이다. 비관적 방식은 사용자가 오래 데이터를 붙잡는 상황에서 확장성이 떨어진다[1]
- 트랜잭션이 복잡하거나 클라이언트가 느려도 낙관적 로킹은 다른 트랜잭션을 막지 않으므로 처리량이 크게 좋아질 수 있다
- 반대로 특정 행에 많은 작업이 몰리는 응용에서는 낙관적 방식의 재시도 비용이 로크 비용보다 커지므로 비관적 로킹이 낫다
- ↑ 1.0 1.1 「Optimistic Concurrency」, ADO.NET, Microsoft Learn, https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/optimistic-concurrency, 확인일: 2026-11-04.
- ↑ Martin Fowler, 『Patterns of Enterprise Application Architecture』, Addison-Wesley, 2002, 16장 Optimistic Offline Lock, Pessimistic Offline Lock.