DB locking은 DB의 동시성 제어 기법 중 하나이다. 다수의 사용자나 프로세스가 DB에 동시에 접근해 데이터를 읽거나 쓰면서 발생할 수 있는 충돌을 방지해 데이터의 무결성을 보장하는 기법이다.
이번 글에서는 DB locking의 기법 중 optimistic locking과 pessimistic locking에 대해 다루어 보고자 한다.
Optimistic locking
DB에서 데이터를 읽거나 수정할 때 lock을 점유하지 않는 기법이다.
특징
Optimistic locking이 적용된 app은 데이터의 수정 / 삭제 작업을 시도할 때 원본 데이터의 변경이 없을 것이라고 가정한다. 만약 원본 데이터에 변경이 발생한 경우 수정/삭제 작업은 실패하게 된다. 이 경우 app logic에서 fail에 대한 핸들링을 해 주어야 한다. (예, Retry; 원본 데이터 다시 읽은 후 작업 재시도)
장점
동시성이 향상(동시에 처리할 수 있는 작업이 많아진다)된다.
단점
그러나 다음과 같은 단점을 수반하기도 한다.
- Fail handling 로직 추가로 인해 application code의 복잡성 증가 여지 있음
- 거짓 부정 혹은 거짓 긍정 문제 발생 가능성 있음.
- 거짓 부정: 데이터가 변경되지 않았지만, 업데이트 시도가 거부되는 현상
- 거짓 긍정: 데이터가 변경되었지만 이를 감지하지 못해 잘못된 데이터가 업데이트 되는 현상
적합한 사용 예
- 동시성 성능 중요한 대규모 시스템
- session 내에서 connection을 유지할 필요가 없는 경우
Pessimistic locking
optimistic locking과 상반되는 개념으로, 충돌이 예상되는 데이터에 미리 접근을 제한하는 기법이다.
특징
트랜잭션이 시작될 때 미리 lock(shared or exclusive)을 hold해 접근을 제한하고 수정 / 삭제 등의 작업을 수행한다. 작업이 완료되면 lock을 해제한다. 트랜잭션을 유지해야 하기 때문에
장점
데이터의 일관성과 무결성을 확실히 보장한다.
단점
데드락 발생 가능성이 있다.
동시 처리 시스템의 성능 저하 원인이 될 수 있다.
적합한 사용 예
- 은행 시스템과 같이 데이터 무결성이 중요한 환경.