[ 데이터베이스 ] 17. LOCK을 활용한 concurrency control ( 2PL protocol )

 

같은 x(데이터) 에 대해 Read / Write 가 있다면 정상적으로 작동하지 않을 것이다.

 

LOCK의 역할이 이 때 쓰인다.

: 데이터마다 LOCK이 있어서, 값을 수정하거나 읽기 위해서 LOCK을 취득해야한다.

  그렇지 않다면 접근이 안 된다.

 

이 기술을 사용하여 동작하는 방식은 아래와 같다

 

 

읽는 거든 쓰는 거든 Lock은 필수다.

 

---

---

 

Write Lock 

: Exclusive라는 특징을 가진다.

 Read를 하든 Write를 하든 하나의 Transaction만 가능하다.

 

 

 

 

Read Lock 

: Shared라는 특징을 가진다.

  다른 Transaction 이 read할 때 read는 같이 해도 됨.

  Write는 같이 X

 

 

Read / Write Lock 예시

 

 

Tx2 에서 Read Lock을 건다.

>  Tx1에서 Write 하기 위해 Lock 걸려고 하는데 이미 하나 걸려있음

>  Tx2에서 끝나서 Unlock 한 뒤에야 write 하면서 lock 함

>  끝나면 Unlock

 

 

 

 

요약

 

---

---

 

Lock을 한다고 다 해결되는 게 아님

 

 

어느 Tx를 먼저 시작하느냐에 따라 결과가 다름

 

 

 

 

 

 

두 Transaction이 순서에 따라 값이 달라진다면 그건 Serializable하다고 할 수 없다.

 

 

 

여기에서 문제는 Tx2에 있는 unlock(x) , write_lock(y) 그 범위가 문제이다.

Tx1에서 read_lock(y)를 하려면 y는 업데이트 된 값을 가져와야한다. 하지만 그냥 기존의 값을 가져오기 때문에

값이 차이가 나버리는 것임.

 

 

 

저렇게 Write와 unlock의 순서만 바꿔도 해결이 된다.

Write(y)에 대한 lock이 걸려있으므로 Tx1에서 read Lock도 획득하지 못한다.

 

따라서 아래와 같은 형태로 변한다.

 

 

 

또 Tx1가 먼저일 때도 마찬가지로

원래 Lock을 해제하기 전에, Write Lock을 받아둠으로써 해결한다.

 

 

여기에서 Lock 관련 Operation들을 한 번 보자

 

 

 

2PL Protocol ( =  2 phase locking )

(read) Lock - (write) Lock - (read) Unlock - (write) Unlock 

순서인 것

 

 

 

 

Deadlock

 

write_Lock(x)는 read_Lock(x)가 끝나길 기다리고 있고

write_Lock(y)는 read_Lock(y)가 끝나길 기다리고 있고

 

누구 만날 때

???: a가면 갈게

     a: b가면 갈게

     b : c가면 갈게...

이런 상황임

 

---

---

2PL Protocol 종류

 

 

 

Conservative 2PL

: 모든 Lock 먼저 취득하고 transaction 시작

 

장점 : Deadlock 없음

단점 : 다 얻고 시작해야해서 실용성 x

 

 

Strict 2PL

: Strict schedule 을 보장하는 2PL

장점 : Recoverability 보장

특징 : Write - lock commit / Rollback될 때 반환

 

 

 

Strong Strict 2PL

: Strict schedule 을 보장하는 2PL

장점 : Recoverability 보장

특징 : [ Write - lock ] + [ Read - Lock ]  모두 commit / Rollback될 때 반환

 

 

 

Write - Lock  +  Write- Lock으로 서로가 Block되는 거 해결법 : MVCC 

 

(출처)

유튜브 쉬운코드