Zettelkasten

2PL Two Phase Locking

·수정 2026.04.24·수정 2

해결하는 문제:

  • Phamtom Read
  • 직렬성 구현 방식
  • 쓰기 트랜잭션은 다른 쓰기 트랜잭션뿐만 아니라 읽기 트랜잭션도 막음(역도 성립)
    • 스냅샷 격리는 읽기는 쓰기를 막지 않고 쓰기도 읽기를 막지 않았음
  • MYSQL(InnoDB), SQL Server에서 직렬성 격리 수준을 구현하는데 사용됨
  • 2단계인 이유 1단계: 잠금을 획득할 때 2단계 모든 잠금을 해제할 때
  • 잠금은 공유모드/독점 모드로 사용됨
    • 읽기 : TR이 객체를 읽기 원한다면 공유모드로 잠금을 획득해야 함, 독점 모드로 잠금을 획득한 TR이 있다면 완료될때까지 기다려야함
    • 쓰기 : TR이 객체에 쓰기를 원한다면 독점모드로 잠금을 획득해야 함, 누군가 모드에 관계없이 잠금을 갖고 있으면 트랜잭션 대기
    • 읽기 ⇒ 쓰기 : 공유잠금을 독점 잠금으로 업그레이드

3.2.1 성능

  • 1970년대 부터 사용하지 않는 이유
  • 완화된 격리 수준을 쓸 때보다 TR 처리량과 질의 응답 시간이 크게 나빠진다.
  • 지연시간이 불안정하고 높은 백분위에서 매우 느릴 수 있음
  • 성능 예측에 어려움을 겪음
  • 교착 상태가 자주 발생함

서술 잠금(predicate lock)

  • 어떤 검색 조건에 만족하는 모든 객체를 잠금
  • row를 잠그는 방법과 동일하게 2PL도 잠글 객체가 존재하지 않으면 대응하지 못하는 거 아니야?
SELECT* FROM bookings WHERE room_id = 123 AND end_time> '2018-01-01 12:00' AND start_time< '2018-01-01 13:00';
  • 미래에 추가될 수 있는 객체들에도 잠금을 걸어둠
  • 매커니즘
    1. 어떤 조건에 만족하는 객체를 읽기 원한다면 질의 조건에 대한 공유모드 서술 잠금을 획득해야함 다른 트랜잭션이 독점모드를 갖고 있으면 기다려야함
    2. 삽입, 삭제, 갱신하기 원한다면 기존 or 새로운 값중에 서술 잠금에 포함되는 값이 있는지 확인 후 있다면 서술 잠금을 갖고 있는지 확인해서 트랜잭션이 커밋 or 어보트 될 때까지 기다려야함

인덱스 범위 잠금(Index Range Locking)

InnoDB는 Next-Key Lock으로 팬텀 리드를 방지한다

이 문서를 참조하는 노트 (1)