Lock을 활용한 Concurrency Control 기법

Youtube 쉬운 코드 채널의 영상을 보고 정리한 내용입니다.
https://youtu.be/0PScmeO3Fig?si=mP1V2HZCoZni1sSt

Lock의 종류

read-lock (shared lock)

read할 때 사용한다.

다른 트랜잭션이 read 하는 것은 허용한다.

write-lock (exclusive lock)

read/write할 때 사용한다.

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

 

❗️ write lock이라고 해서, write할 때만 사용되는 것은 아니다! exclusive한 형태라는 점이 중요하다.

 

lock 호환성

같은 데이터에 대해서, 한 트랜잭션이 어떤 lock을 가지고 있을 때, 다른 트랜잭션도 lock을 동시에 가질 수 있을까?

같은 데이터에 대해서, 한 트랜잭션이 read lock을 가지고 있을 때 다른 트랜잭션에서 동시에 read lock을 가지려고 하는 경우
를 제외하면 모두 불가능하다. 
이미 있는 lock이 해제될 때까지 기다려야 한다.

	read-lock	write-lock
read-lock	O	X
write-lock	X	X

 

Lock 사용 시 이상현상과 2PL

Lock을 사용해도 이상한 현상이 발생할 수 있다.

예를 들면

서로 다른 트랜잭션이 두 데이터 x, y에 대한 작업을 할 때, 각 데이터에 대한 lock 취득 시점, 데이터를 읽는 시점이 다름으로 인해

Nonserializable한 스케줄이 될 수도 있다.

x=100, y=200일 때
T1은 x와 y의 합을 x에 저장 / T2는 x와 y의 합을 y에 저장한다고 하자.
serial schedule이라면, 트랜잭션의 순서에 따라 x, y의 값은 서로 다르다. (300,500 or 400, 300)
하지만 lock을 사용할 때 다음과 같이 동작한다면 nonserializable한 결과가 나온다. (300, 300)

(1) T2가 read_lock(x)에 대한 unlock을 하는 사이에 T1이 read_lock(y)을 획득
(2) T2의 write_lock(y)는 T1의 read_lock(y)이 끝날 때까지 대기 후, 끝나면 y에 대한 쓰기 작업을 진행
-> T2가 먼저 시작했음에도 T1은 T2가 업데이트하기 전의 y의 값을 읽게 된다.

 

이 현상을 해결하기 위해 2PL을 통해 serializability를 보장한다.

어떻게?

예시로 다시 보자면

T2가 먼저 시작됐다면, T2가 x, y 모두에 대해 먼저 lock을 획득하도록 하자.
T2가 read_lock 으로 x를 읽고, write_lock으로 y를 읽고 쓰는 작업을 먼저 하도록 한다.
이 때 write_lock(y)를 걸어둔 상태이므로 T1의 read_lock은 대기한다.
unlock(x), unlock(y)가 모두 다 된 뒤에야 T1의 읽기, 쓰기 작업이 진행된다.
-> serializable을 보장하게 된다!

반대로 T1를 먼저 시작하는 경우에도, serializable을 보장하기 위해서는
위 이미지에서 unlock(y) <-> write_lock(x)의 위치를 바꿔주어야 한다.
unlock(y)를 하는 사이 T2에서 먼저 x에 대한 lock을 획득할 수 있기 때문이다.

 

 

Two-Phase Locking (2PL)

위 해결방법이 2PL 방식인데,

트랜잭션에서 모든 locking operatrion이 최초의 unlock operation 보다 먼저 수행되도록 하는 것이다.

이것을 two-phase locking, 2PL protocol이라고 한다.

취득만 하는 phase와, 반환만 하는 phase로 나누어져 있다는 뜻이다.

다르게 설명하면, 한 번 unlock이 시작되면 그 이후에는 새로운 lock의 취득을 하지 않는다고 볼 수 있다.

Expanding phase (growing phase)

lock을 취득하기만(read_lock, write_lock) 하고 반환하지는 않는 phase 

Shrinking phase (conracting phase)

lock을 반환만(unlock) 하고 취득하지는 않는 phase

 

2PL은 특별한 경우를 제외하면 seralizablity를 보장해준다.

따라서 2PL protocol을 따르도록 RDBMS를 구현하면, 이 때 Concurrency control은 serializability를 보장한다.

(하지만 상황에 따라 데드락이 발생할 수 있다는 점은 알고 있어야 한다.)

 

 

2PL의 종류

Conservative 2PL

모든 lock을 취득한 뒤 transaction을 시작한다. (읽기/쓰기 작업 중간에 lock 취득, 반환이 이루어지지 않음)

-> 데드락이 발생하지 않지만, 실용적이진 않다.

Strict 2PL (S2PL)

Strict schedule 을 보장하는 2PL 
(어떤 데이터에 대해 write하는 트랜잭션이 있다면, 그 트랜잭션이 끝(커밋/롤백)나기 전까지는 다른 트랜잭션이 그 데이터에 대해 읽거나 쓰지 않는 스케줄)
write-lock을 commit/rollback될 때 반환한다. (read-lock은 스케줄 내에서 반환 가능)
-> recoverability를 보장한다. 

Strong Strict 2PL (S2PL)

read-lock 또한 commit/rollback될 때 반환한다.
-> S2PL보다 구현이 쉽다. 대신 lock을 더 오래 쥐고 있어야 한다.

 

2PL의 약점

lock 호환성을 봤을 때, 

read-read를 제외하고는, 항상 한쪽이 block이 되니까 전체 처리량이 좋지 않다.

(그래서 read-write 간의 호환성이라도 더 챙겨보고자 나온 동시성 제어 방식이 MVCC이다.)

---

답해보기

2PL을 구현하는 이유는?

동시성 제어의 방법으로 Lock을 사용하는 것만으로는 Serializablity를 항상 보장할 수 없다. 따라서 Serializability를 보장하기 위해 2PL을 구현한다. 2PL은 취득과 반환 phase를 나누기 때문에 unlock을 하는 사이 다른 트랜잭션이 먼저 lock을 취득하여 작업을 하는 것과 같이 순서를 보장하는 일을 방지할 수 있다.

 

2PL 방식으로 구현할 때 데드락의 예시는?

위에서 다뤘던 x+y 를 x, y에 저장하는 예시로 보자면
T1은 read_lock(x)를 가지고 있고 write_lock(y)를 받기를 기다리고 있다.
T2은 read_lock(y)를 가지고 있고 write_lock(x)를 받기를 기다리고 있다.  
그러면 둘 다 shrinking phase가 끝나야 반환을 하므로 자신의 lock을 반환하지 않고 서로 기다리는 교착 상태가 발생한다.