Multiple Granularity Locking

Multiple Granularity Locking

다양한 사이즈의 data item 에 대해 lock 을 걸 수 있다.

- Fine granularity

레코드 단위로 잘게 쪼개어 락을 관리 -> 동시성 증가, lock overhead 증가

- Coarse granularity

테이블처럼 큰 단위로 락을 관리 -> 동시성 감소, lock overhead 감소

 

Intention lock Modes

노드 N에 대해 Intention lock 을 건다는 것은 미래에 N의 하위 노드에 (S or X)락을 걸겠다는 것이다.

Intention-shared(IS) : Intention Shared Lock

Intention-exclusive(IX) : Intention Exclusive Lock (X or S lock)

Share and intention-exclusive(SIX) : Shared + Intention Exclusive Lock = S + IX 

-> 현재 노드는 S lock 을 걸고, 미래 하위노드는 S or X lock

 

 

Intention lock 은 큰 단위의 granularity에 락을 걸 때 모든 하위 노드의 lock 검사해야 하는 overhead 를 줄여준다.

 

ex) 

 

top 에서부터 내려오면서 database -> relation -> page -> record 로 단위가 감소한다.

만약 트랜잭션이 DB 에 S-lock 을 걸고 싶다면, DB의 하위 노드에 이미 lock 이 걸려있는 노드가 있는지 모두 체크해야 한다.

이런 불편함을 해소해주는 것이 intention lock 이다.

 

즉, intention lock 을 사용하는 상황은 다음과 같다.

1. 트랜잭션이 DB 에 S-lock 을 걸고 싶어한다.
2. lock manage 은 DB 에 어떤 lock 이 존재하는지를 살펴본다.
3. 이미 DB 에는 IX 가 존재한다. 따라서 IX 와 S lock 이 compatible 한지 살펴보고, 그렇지 않다는 결론이 나온다.
4. 따라서 DB 에 S-lock 을 걸 수가 없어, wait 하게 된다.
-> locking overhead 감소

 

Intention Lock Modes 의 Compatibility matrix 이다.

 

Multiple Granularity Locking (MGL) Scheme

트랜잭션 Ti 는 다음가 같은 규칙을 따를 때 node Q 에 락을 걸 수가 있다.

- lock compatibility matrix 를 충족해야 한다.
- 트리의 root 에 가장 먼저 lock 이 걸려야 한다. (어떤 mode 이던지 간에)
- 노드 Q에 S 또는 IS 락을 걸려면 그 부모 노드가 IX 또는 IS 락을 가진 상태여야한다.
- 노드 Q에 X, SIX, IX 락을 걸려면 그 부모 노드가 IX 또는 SIX 락을 가진 상태여야한다.
- Two-phase 를 따르기 때문에 어떤 락이든 해제한 적이 있다면 그 뒤로는 락을 다시 얻지 못한다.
- 노드 Q의 락을 해제하고 싶다면 하위 노드 중 락이 걸린 노드가 없어야 한다.

 

ex1 )

-> lock conflict 가 없다. IS, IX 는 compatible 하기 때문이다.

 

ex2 )

->  lock conflict 가 없다. IS, IX / IS, SIX는 compatible 하기 때문이다.

 

 

​->  lock conflict 가 존재한다. IX, SIX는 incompatible 하기 때문이다. T2는 기다려야 하며, T1 이 Unlock(R1) 을 한 후에 다시 실행될 수 있다.​