Recoverablilty

Concurrency control은 Serializable과 Recoverablilty를 제공하기 위한 것이다.
1편에서는 Serializable에 대해서 다뤄보았고, 이번에는 Recoverablilty에 대해서 알아보자.

Keyword
recoverable schedule, cascadeless schedule, strict schedule

unrecoverable schedule

1. tx1 이상없이 수행되어 commit 완료. (DB에 영구적으로 적용)
2. 그러나 tx2는 오류가 발생하여 rollback.(H의 balance = 200만원)
3. tx1가 H_balace를 읽어올 때, tx2의 write(H_balance = 230만원) operation을 참조했기 때문에, tx1도 유효하지 않은 작업이므로 rollback을 시켜야한다.

그러나, tx1는 이미 commit된 상태이므로, durability 속성 때문에 rollback할 수 없다.

이렇게 schedule 내에서 commit된 트랜잭션이(tx1),
rollback된 트랜잭션(tx2)의 write 했던 데이터를 읽은 경우를 의미한다.
unrecoverable schedule은 rollback을 해도 이전 상태로 회복이 불가능 할 수 있기 때문에 DBMS가 허용하면 안된다

그럼 DBMS는 어떤 schedule만을 허용해야 할까??
바로 recoverable schedule이다.

recoverable schedule

rollback할 때 이전 상태로 온전히 돌아갈 수 있기 때문에 DBMS는 recoverable schedule만 허용해야 한다.
recoverable schedule에서 rollback 시에는, cascading rollback이 발생한다.

cascading rollback

어떤 경우에 cascading rollback이 발생할 수 있을까?

1. tx1가 H_balance=230만원을 read한다.
2. 이 때, tx1가 read한 H_balance는 tx2가 write한 데이터이다.
3. write operation을 수행한 tx2가 commit/rollback 하기 전까지 tx1는 commit하지 않아야 한다.
   
   schedule 내에서 그 어떤 트랜잭션도 자신이 read한 데이터를 write한 트랜잭션이 먼저 commit/rollback 하기 전까지는 commit을 하지 않는 경우에 발생한다.

• 하나의 트랜잭션이 rollback하면 의존성이 있는 다른 트랜잭션도 rollback 해야한다.

하지만 여러 트랜잭션의 롤백이 연쇄적으로 일어나면 처리하는 비용이 많이 든다.

이 문제를 어떻게 해결할 수 있을까?

데이터를 write한 트랜잭션이 commit/rollback 한 뒤에 데이터를 읽는 schedule만 허용하자.

tx2에서 문제가 발생되게 되면 rollback을 시키고, 아무일도 없었던것 처럼 tx1만 완료된다.

cascadeless schedule

schedule 내에서 어떤 트랜잭션도
commit 되지 않은 transaction들이 wirte한 데이터는 읽지 않는 경우를 의미한다.

cascadeless schedule도 어떤 상황에서는 문제가 있을 수 있다.

상황설명

사장 H가 3만원이던 피자를 2만원으로 낮추려는데
직원 K도 동일한 피자의 가격을 실수로 1만원으로 낮추려 했을 때.

1. 직원 K가 1만원으로 가격을 변경함. 아직 commit은 하지 않음.
2. 사장 H도 2만원으로 가격을 변경하고 commit
3. tx1에서 이슈가 발생해서 rollback.
4. 최종적으로 피자의 가격은 결국 3만원으로 원복됨. (tx2의 결과가 사라짐)
   
   이 schedule은 cascadeless schedule이지만 tx2의 결과가 사라지는 문제가 발생한다.

위의 문제를 해결하기 위해서는 cascadeless schedule에 조금 더 보완이 필요하다.

Strict schedule

schedule 내에서 어떤 트랜잭션도
commit 되지 않은 transaction들이 wirte한 데이터는 쓰지도, 읽지도 않는 경우를 의미한다.
strict schedule이 발생하기 위해서는 tx1가 먼저 commit/rollback 작업이 이루어져서 끝나고 난 뒤에 tx2가 실행되어야 한다.
이러한 strict schedule의 형태는 rollback이 쉽다는 장점이 있다.

결론은??
Serializable과 Recoverablilty에 대한 개념을 잘 잡아놓자.

Concurrency control은 Serializable과 Recoverablilty를 제공하기 위한 것이다.

Reference
쉬운코드(yotube) - 데이터베이스 시리즈 (Concurrency control 2편)