동시 실행 제어
T1이 자원 B에게 쓰기 위해서 배타적 락을 건다. B-50을 쓰고 배타적 락을 푼다. (unlock B) 이 때 트랜잭션 T2에서 B에 공유 락을 걸어서 읽는다. 그럼 inconsistency한 상태를 읽어버리는 것이다. T1에서 B에 대한 락을 너무 일찍 풀었기 때문이다.
이런식으로 unlocking을 delay시키면 된다. 그럼 나중 트랜잭션이 바로 끼어들어도 inconsistence한 상황을 보지 못한다.
여기서 문제가 발생한다. DeadLock이라는 문제가 발생하는데 데드락이란 두 트랜잭션이 서로가 가진 자원을 이용하려고 계속 기다리는 상태를 말한다. 발생을 한다면 둘 중 중 하나의 트랜잭션을 roll back 시켜줘야 한다.
T3에서 B에 락을 걸어놓은 상태에서 A에도 락을 걸으려고 한다. 그런데 T4는 이미 A에게 락을 건상태에서 B에 락을 걸려고 한다. 그럼 서로 무한히 기다리는 상태가 된다.
cf) 기아 상태 : 기아상태란 교착상태와는 다르게 서로 기다리는 것을 예방하기위해 우선순위를 부여하여 자원할당을 했을 때 아예 실행될 수 없는 (우선순위가 낮은데 계속 높은 애들이 들어올 때) 것이 생기는 것. (교착상태는 자원을 자유롭게 할당한 결과에서 나온다)
2. Two-Phase Locking Protocol (2단계 락킹 기법)
직렬성(serializability)을 보장하는 프로토콜이다. 모든 트랜잭션들이 lock과 unlock을 구분하여 수행한다.
2-1) Growing Phase : (확장단계) Lock을 수행할 수는 있지만 풀 수는 없다.
2-2) Shrinking Phase : (수축단계) Lock을 수행할 수는 없지만 풀 수는 있다.
진행단계 : 초기에는 트랜잭션이 growing phase 이다. 그리고 락이 하나 풀린다면 Shrinking Phase에 들어가서 락을 더 이상 걸수는 없게 만드는 것이다. 하지만 여기서도 데드락이 발생할 수는 있지만 적어도 conflict serializability는 보장한다. 데드락이 발생하면 롤백 시킨다.
2단계 락킹 기법의 2가지 유형
* Strict two-phase locking protocol
- casecading rollback을 방지한다. (cascade rollback의 원인은 commit되지 않은 것들을 읽어서 발생한다.)
- exclusive lock이 commit되지 않은 데이터에 접근을 하지 못하게 한다.
* Rigorous two-phase locking protocol
- 모든 lock이 commit되지 않은 데이터에 접근을 하지 못하게 한다.
- 이 유형은 상용 db에서 많이 쓰인다.
3. Lock Conversion
이 상황에서는 a1을 쓰는 작업이 T8의 끄트머리에 존재한다. 위의 two-phase 락킹 프로토콜을 사용한다면 초기부터 a1에 대해 exclusive lock을 걸 것이므로 T9가 실행을 못하고 기다린다. T9는 보면 단순히 a1을 read하는 것 밖에 없다. 그래서 약간의 병렬성이라는 것을 줄 수 있다.
4. Snapshot Isolation
실행을 시작할 단계의 데이터베이스의 사진을 찍는다. 장점 : Read는 블록 당하지 않는다. dirty read를 방지한다. 단점 : 항상 serializable한 실행을 보장하지 않는다.
'프로그래밍 > Database' 카테고리의 다른 글
| MySQL의 Between 쿼리 개선하기 (0) | 2021.04.10 |
|---|---|
| MySQL 잠금과 Isolation level에 대해서 (2) | 2021.01.16 |
| [데이터베이스] 트랜잭션(Transaction)에대한 고찰 (2) | 2018.12.16 |
| [데이터베이스] 쿼리 최적화에 대해서 (Query Optimization) (2) | 2018.12.16 |
| [데이터베이스] 트랜잭션에 대해서 (0) | 2017.05.28 |