Optimistic Lock vs Pessimistic lock
[ Stackoverflow ] Optimistic Lock vs Pessimistic lock
두 번의 갱신 분실 문제(second lost updates problem) → 데이터베이스 트랜잭션 범위를 넘어서는 문제
- 사용자 A와 B가 동시에 제목이 같은 공지사항을 수정할 때, A가 먼저 수정완료 버튼을 누르고 B가 수정완료 버튼을 누르면 A의 수정사항은 사라지고 B의 수정사항만 남게 됨
- 이를, Optimistic locking 혹은 pessimistic locking을 이용해서 해결이 가능함
Optimistic locking(↔ Conditional Update, Compare-And-Update) : 변경이 Database에 커밋될 때만 record에 잠금 걸림
- 레코드에 대한 잠금을 사용하지 않고 동시성 제어를 수행함
- version 값(timestamp, checksum, hash도 가능)을 이용하여 수정 작업할 때, 이전에 가져왔던(읽었던) 데이터의 version 값과 현재 version 값이 동일할 때만 수정을 진행함
- Optimistic locking에서는 다수의 유저가 하나의 record를 업데이트 하는 시도를 허용해 줌 (어떤 유저가 해당 record를 업데이트 하고 있다는 것을 다른 유저들은 알 수 없음)
- record의 변경은 record가 커밋될 때에만 유효함
- ⇒ 그래서, 한 유저가 record 수정에 성공했을 때, 수정을 하고 있었던 다른 유저들은 충돌이 발생 된다는 것을 알게 됨
- 사용 시점 : 동시적으로 record를 업데이트 하는 상황이 빈번하지 않거나 락의 오버헤드가 높은 상황에서 좋은 접근법임
- 단점 : 다수의 사용자가 record를 concurrent하게 수정할 시, 한 사용자의 변경이 커밋되면 다른 유저들의 변경사항은 반영되지 못하고 충돌이나게 되고 일일이 병합작업을 수동으로 해주어야 함
Pessimistic locking : 수정 되는 도중에는 record에 잠금 걸림
- 비관적 락은 record에 대한 동시적인 변경 자체를 방지함
- 임의의 사용자가 레코드를 변경하기 시작하면 lock이 걸리게 되고 다른 유저는 해당 record에 수정 자체를 시도할 수 없음
- 장점
- 충돌 자체를 방지하기 때문에 conflict resolution에 대한 문제가 없음
- 수정이 직렬화되고 이전 사용자가 변경한 record로부터 순차적인 수정이 들어가게 됨
- 사용시점 : 비관적 락은 수정작업이 지연이 되어도 괜찮을 때 사용해도 좋음. 주로 수정이 짧은 시간내에 이루어지는 작업일 때
- 두 개다, DB에 변경사항이 커밋되고 난 후에 잠금 해제 됨