[DB] LOCK을 활용한 Concurrency Control 기법

개바리여리 2025. 8. 24. 02:31

## 유튜버 '쉬운코드' 님의 강의 영상을 개인공부를 위해 정리한 내용이여서 매우 함축적이며 요약된 것입니다.

락(lock)

데이터의 동시 접근 충돌을 막기 위해 잠그는 장치

* 락이 필요한 이유

- 여러 사용자가 동시에 같은 데이터를 읽거나 수정하려고 할때 이상현상이 발생할 수 있음.

- 락을 걸어서 데이터의 일관성을 유지해주기 위해서 ( A가 계좌 잔액을 읽는 동안, B가 동시에 잔액을 바꿔버리면 A의 결과는 신뢰할 수 없음 )

- Write Lock (Exclusive Lock)

다른 트랜잭션이 같은 데이터를 read/write 하는 것을 허용하지 않음.

- Read Lock (Shared Lock)

read할때 사용하며, 다른 트랜잭션이 같은 데이터를 read하는 것은 허용하지만 쓰기작업은 허용하지 않는다.

예시:

1. T2(Transaction2)가 read_lock를 획득

2. T1이 write_lock 획득을 시도하지만 T2가 read_lock을 가지고 있기에 실패 (블로킹)

3. T2가 x 값을 읽으며 락을 반환

4. T1은 블로킹이 해제되며 쓰기작업을 하고 write_lock을 반환

* 락을 사용하여도 이상현상이 발생하는 경우

T1이 먼저 실행되고 T2가 실행되는 경우 최종결과값 : x -> 300 , y -> 500

T2가 먼저 실행되고 T1이 실행되는 경우 최종결과값: x-> 400 , y -> 300

위와 같이 락을 사용하여도 두 트랜잭션의 순서가 섞이면 x = 300, y = 300 와 같은 이상현상이 발생할 수 있다.

--> 업데이트 되지 않은 값들을 읽거나 쓰기 작업을 하기 때문에 발생한다.

이러한 문제는 2PL Protocol 을 통해 해결할 수 있다.

트랜잭션에 모든 lock 작업이 최초 unlock 작업보다 먼저 수행되도록 하는 기법

- Expanding phase

Lock을 취득하고 반환하지 않는 페이지

ex : read_only (y) , write_lock (y) 등

- Shrinking phase

lock을 반환만 하고 취득하지 않는 페이지

ex : unlock (y) 등

하지만 2pl 프로토콜을 사용하면 어쩌다가 데드락이 발생할 수도 있다.

서로가 서로의 자원을 기다리는 데드락 상황이 발생한다.

데드락이 발생하지 않는 conservative 2PL 방식도 존재한다.

이 방식은 일단 모든 lock (read_lock, write_lock)을 취득한뒤에 트랜잭션을 시작하는 기법이나

실용적이지 않다고 한다.

그 밖에도

write_lock을 커밋 or 롤백 될때 반환하는 strict 2PL 프로토콜이 존재한다.

* 자세한 내용은 아래 링크를 통해 영상 시청하는 것을 권합니다. (좋은 내용이 많이있음.)