Lock
트랜젝션은 데이터에 접근하기 위해 lock을 실행해 독점권을 얻음
다른 트랜잭션에 의해 이미 lock이 실행된 데이터는 lock 연산을 할 수 없음
lock을 한 트랜잭션은 unlock을 해서 독점권을 반납해야함.
-> 이렇게 하면 효율성이 너무 떨어진다. 읽는건 상관 없지 않나? 안변하잖아!
동시에 read 연산을 실행하게 허용하는 lock 방식
공유(Shared) Lock
공유 Lock은 데이터를 읽을 때 사용되어지는 Lock입니다. 이런 공유 Lock은 공유 Lock 끼리는 동시에 접근이 가능합니다. 즉, 하나의 데이터를 읽는 것은 여러 사용자가 동시에 할 수 있다라는 것입니다. 하지만 공유 Lock이 설정된 데이터에 베타 Lock을 사용할 수는 없습니다.
베타(Exclusive) Lock
베타 Lock은 데이터를 변경하고자 할 때 사용되며, 트랜잭션이 완료될 때까지 유지됩니다. 베타락은 Lock이 해제될 때까지 다른 트랜잭션(읽기 포함)은 해당 리소스에 접근할 수 없습니다. 또한 해당 Lock은 다른 트랜잭션이 수행되고 있는 데이터에 대해서는 접근하여 함께 Lock을 설정할 수 없습니다.
-> 공유 공유 읽기 가능
이럼에도 문제가 생긴다
트랜잭션 T14와 T15가 동시에 실행하는데 T14에서 write(x) 연산과 X-lock(y) 연산 사이에 T15가 실행된다고 가정해보자.
(T14) X-lock(x) ··· T14가 x에 대해 X-lock을 얻고
(T15) S-lock(y) ··· 후에 T15가 y에 대해 S-lock을 얻는다.
여기까지는 서로 다른 데이터 항목 x, y에 대해 잠금을 설정한 것이므로 문제가 없다.
(T15) S-lock(x) ··· 그 다음 T15가 x에 대해 S-lock를 요청했을 때, T14가 이미 X-lock을 보유하고 있기 때문에 T14가 unlock하기 전까지 대기해야 한다.
(T14) X-lock(y) ··· T14가 y에 대해 X-lock을 요청하면, 이미 T15가 y에 대한 S-lock을 얻었기 때문에 T14 또한 T15가 unlock하기 전까지 대기하게 된다.
결국 T14, T15가 모두 대기 상태에 들어가 더 이상 진행하지 못하게 되고, 이런 상태를 교착상태(deadlock)라고 한다.
교착상태에 빠지면 외부에서 강제로 트랜잭션을 중단하거나 잠금을 해제하지 않는 이상 무한정 대기 상태로 남게 된다.
DB에 반영되기 전에 read를 하는 경우!
2단계 잠금 규약(2-Phase Locking protocol : 2PL)
그래서 이러한 동시성을 보완하기 위해 2단계 locking 규약이 있다.
2PL은 잠금을 설정하는 단계와 해제하는 단계로 나누어 수행한다.
확장단계(growing phase)
: 트랜잭션이 lock 연산만 수행할 수 있고 unlock 연산은 수행할 수 없는 단계
축소단계(shrinking phase)
: 트랜잭션이 unlock 연산만 수행할 수 있고 lock 연산은 수행할 수 없는 단계
-> 쉽게 lock만 해서 같은걸 계속 보다가 누가 한번 unlock을 하면, 그 전게 모두다 unlock이 되어 반영이 되어야 다시 lock을 통해 접근할 수 있다.
이렇게 하면 완료되지 않은 트랜잭션에 의해 갱신된 데이터를 다른 트랜잭션이 읽거나 쓸 가능성을 원천적으로 봉쇄할 수 있어 연쇄 복귀 문제를 해결할 수 있다. 현재 대부분의 DBMS에서 엄격한 2PL 규약을 이용하여 동시성 제어를 구현한다.
