lock

 

 

---

공통 질문

 

 

---

 

출처: https://www.youtube.com/watch?v=0PScmeO3Fig

 

 

---

 

 

 

write lock == exclusive lock

- write 불가능

- read 불가능

transation2는 기다린다

 

transaction1이 write lock 해제해야 접근 가능하다

 

 

transaction2는 write lock 을 획득한다

 

 

write lock 일때 read도 기다린다

 

 

---

read lock == shared lock

- read 가능

- write 불가능

 

transaction1은 read lock으로 잠근다

 

---

lock 호환성

---

lock 예제 1(읽기, 쓰기)

- transaction2가 먼저 시작

 

read lock 이 먼저 실행되서 write는 기다린다

 

 

 

lock 예제 2(읽기, 읽기)

- transaction2가 먼저 시작

서로가 서로에게 영향을 주지 않는다

 

---

lock 예제 3(읽기-쓰기, 읽기-쓰기)

 

transaction1이 먼저 수행되고, transaction2가 실행된 결과

 

transaction2이 먼저 수행되고, transaction1 실행된 결과

 

 

두 개가 섞이게 되면?

transaction2가 먼저 시작

 

y를 100+200 ->  300으로 update

 

 

x를 200 + 100 -> 300 update

 

결과가 이상하다.. == non serialalizable

 

 

원인이 뭘까?

read-lock

 <--------------- read-lock을 풀었네?

write-lock

 

이 부분이 문제이다.

- transaction1에서 데이터를 읽을때 transaction2에서 update 되지 않은 data를 먼저 읽어서 사용해서 문제이다

 

 

해결방법?

순서를 바꿔라

transaction1이 읽지못하면서 아래 내용이 바뀌게 된다

 

변한 모습.. serialiable하게 변함

 

write lock을 unlock 보다 위로 옮겨라

 

 

 

---

2PL protocol

- expanding phase : lock 취득만 함

- shiriking phase: lock 반환 만 함

- serializable을 보장한다

 

 

 

---

2PL protocol 문제점

1. 데드락

 

2. 처리량이 낮음

 

해결 방법: mvcc

---

conservative lock

모든 lock을 취득한 뒤 transaction을 시작한다

before

x, y, z lock 걸기

- x read lock

- y,z write lock

 

after

- x,y,z lock을 맨 위로 올림

- 데드락 발생 X

 

 

---

Strict 2PL

- write lock 을 commit 이후에 unlock 

before

 

 

after

- y,z write lock 을 commit 이후에 unlock 적용

 

---

String Strict 2PL

- read, write lock 을 commit 이후에 unlock 

before

 

 

after

- x, y,z readm write lock 을 commit 이후에 unlock 적용

 

장점

 

단점

read lock을 너무 오래 잡고 있는다

그래서 다른 transaction이 read하는데에 기다려야한다