Concurrency Control

Concurrency Control: 동시성 제어

 

Lock-Based Protocols

database conflict를 방지하기 위한 프로토콜

Lock: data에 잠금을 걸어서 접근하지 못하게 함

 

exclusive (X) mode: lock을 건 해당 transaction은 data 읽기 쓰기 모두 가능/ 나머지 transaction은 접근 불가능

shared (S) mode: lock을 건 해당 transaction은 data 읽기만 가능/ 나머지 transaction도 동시에 shared lock을 걸 수 있음

 

절차: lock requests를 먼저 하고 이후 granted되어 lock을 건다.

 

Lock-compatibility matrix

누군가 lock이 필요한 작업을 하려고 하는데 lock grant가 나지 않으면 grant가 될 때 까지 기다리게 된다.

 

B에 lock을 걸어놨기 때문에  T4의 B는 T3가 끝날때 까지 접근할 수 없다.

 

Deadlock: 두 tesk가 서로 하나의 자원을 점유하고 다른 서로의 자원을 요청하여 기다리고 있는 상태

하지만 자원을 오래 점유해야 일관성이 유지가 잘 되는데 오래 점유하면 deadlock이 발생하게된다.

deadlock은 필요악이다.

 

Starvation(기아 현상): exclusive의 grant 우선순위가 계속 뒤로 밀려 grant를 받지 못하는 현상 

T2가 Q에대해 shared lock을 가지고 있음
T1는 Q에대해 exclusive lock을 요청, wait함,
T3는 Q에대해 shared lock을 요청, grant됨
T2 종료,
T4가 Q에대해 shared lock을 요청, grant됨
T3 종료,
T1는 절대 exclusive lock을 grant받을수 없다.
이를 starvation이라고 함

 

Two phase Locking protocol: 페이즈를 나눠 한번에 쫙 lock주고 한번에 쫙 lock 풀고 

- growing phase: lock을 받기만 함

                  - 할일 함 - 

- shrinking phase: lock을 release만 함

 

strict two phase locking protocol: 덜 빡셈

- 모든 exclusive lock을 transaction이 commit 할때까지 놓지 않는다.

- deadlock은 여전히 존재한다.

rigorous two phase locking protocol: 빡셈

 - 모든 lock을 commit할때까지 놓지 않는다.

 - concurrency(동시실행)는 줄어들게된다

 

Lock conversions: lock을 upgrade downgade 함

당장 X lock까지는 필요하지 않고 S lock 만 있으면 된다면 S 만 가지고 있다가, 이후에 X lock으로 upgrade하는 방법

반대도 마찬가지, X 가지고 있다가 S만 있으면 되게 되면 downgrade 한다.

 

Automatic Acquisition of Locks: lock 풀리는거 대기

 - read() : 내가 S lock가지고 있는거 있으면 바로 read 하고, 없으면 lock 기다렸다가 하고 read

 - write(): 내가 X lock가지고 있는거 있으면 바로 write 하고, 없으면 lock 기다렸다가 하고 write

 

dead lock prevention

 

Preemption and transaction rollbacks

• wait-die: 늙은 transaction은 젋은놈 기다리고, 젋은놈은 늙은놈 안기다리고 자살(rollback) 한다.
• wound-wait: 늙은 transaction은 젋은놈을 죽여버리고(rollback 시켜벌림), 젊은놈은 늙은놈 기다린다 

Timeout-Based Schemes: 일정시간만 기다리다가 지나면 rollback한다.

 

 

Dead lock detection & recovery

필요로 하는 자원 요청에 cycle이 생기면 dead lock이 생김을 알 수 있다. -> detect

 ->어떤 transaction은 rollback되어야 한다.

 ->가장 작은 비용을 가진 victim을 고르자 (둘중 하나 골라)

• 트랜잭션 자체를 abort
• 데드락을 없앨정도만 rollback한다.

Multiple granularity :database/ area/ file/ record 의 크기로 나눠 영역별로 lock을 거는 형태

 크기의 단계가 생기면서 lock의 종류도 다양햐진다

 intention-shared (IS) : 하위 단계 어딘가에 Slock을 걸것이다 하는 lock

 intestion-exclusive (IX) : 하위 단계 어딘가에 Xlock을 걸것이다 하는 lock

 shared and intention-exclusive (SIX): 루트는 Slock, 하위 어딘가에는 Xlock을 걸것이다.

Multiple granularity

 

Snapshot Isolation: 트랜잭션마다 sanpshot을 찍어 그 안에서 트랜잭션을 수행한다: 완전한 isolation

 first committer wins : 한 자원을 가지고 먼저 commit 한 T가 반영되고 늦은 T가 물러야 하는 규칙

 first-updater-wins : 먼저 update하는놈이 이긴다. 이미 다른 transaction이 업데이트하면, abort한다.

 - Tj가 아이템에대헤 lock을 가지고있으면, Ti는 Tj가 abort나 commit할때까지 기다린다.

 

Snapshot Isolation의 장점 

• 읽는행위는 절대 block되지 않는다.
• read commited와 perfomance가 비슷하
• No dirty read, No lost update, No non-repeatable read

문제점: 순차적으로 transaction이 일어났을때 생기는 효과를 보지 못한다.

• write skew
• 서로 다를 아이템들을 수정할때, 그 사실을 모르면 isolation이 깨진다.