DB

Deadlock

아뵹젼 2022. 4. 20.

Deadlock

위와 같이 모든 트랜잭션이 다른 트랜잭션이 release 하기를 wait 하는 상황이면 deadlock 이다.

 

Deadlock Handling

Timeout-based Schemes

일정 시간이 지나도 응답이 없으면 해당 트랜잭션을 rollback

-> 구현은 쉬우나 starvation 발생한다.
-> 적절한 시간 설정이 어렵다.

Deadlock prevention protocol

트랜잭션 수행 전에 모든 데이터에 lock 을 검사한다.

모든 데이터 아이템에 부분적인 순서를 두고, 트랜젝션이 아이템들을 이 순서에 따라 lock하도록 한다. (graph-based)

 

Wait-die/Wound-wait Schemes

deadlock을 방지하기위해 트랜잭션 timestamps를 사용한다.

Wait-die scheme

- 비선점 방식

- Old 트랜잭션은 Young 트랜잭션이 데이터 아이템을 내려놓을 때 까지 기다린다. (Wait)

- Young 트랜잭션은 Old 트랜잭션을 기다리지 않고 rollback한다. (Die)

- 트랜잭션은 필요한 아이템을 얻기 위해 여러번 rollback 당할 수 있다.

Wound-wait scheme

- 선점 방식

- Old 트랜잭션은 Young 트랜잭션을 rollback 시킨다. (Wound)

- Young한 트랜잭션은 Old한 트랜잭션을 기다린다. (Wait)

- wait-die 보다 rollback이 적을 수 있다.

 

-> 두 정책에서, rollback된 트랜잭션은 기존 타임스탬프를 가지고 재시작한다.
따라서 언젠가는 가장 old 한 트랜잭션이 될 것이기 때문에 starvation 이 발생하지 않는다.

 

Deadlock Detection 

wait-for graph(prededence graph) 에 사이클이 존재한다면 deadlock 이 발생한다.

deadlock이 발생했다면 victim 트랜잭션을 선정하여 rollback시킨다.

victim은 rollback하는데 최소의 비용이 드는 트랜잭션이다.

Total / Partial rollback

Total : 트랜잭션을 abort하고 재시작한다.
Partial : deadlock을 없애기 위해 필요한 만큼만 rollback -> 더 효율적

-> 항상 같은 트랜잭션이 Victim으로 선정되면 Starvation이 일어난다.

 

사실 Lock waits 도 거의 일어나지 않으며, deadlock 은 거~의 발생하지 않는다고 봐도 무방하다.

'DB' 카테고리의 다른 글

Failure and Recovery  (0) 2022.04.21
Insert and Delete Operations  (0) 2022.04.20
Multiple Granularity Locking  (0) 2022.04.20
Lock-based Protocols  (0) 2022.04.20
Recoverability  (0) 2022.04.19

댓글