16. concurrency control - 2

unrecoverable schedule

- schedule 내에서 commit된 transaction이 rollback된 transaction이 write 했었던 데이터를 읽은 경우

unrecoverable schedule 예시

 

recoverable schedule

- schedule 내에서 그 어떤 transaction도 자신이 읽은 데이터를 write한 transaction이 먼저 commit/rollback 전까지는 commit 하지 않는 경우

- rollback할 때 이전 상태로 온전히 돌아갈 수 있기 때문에 DBMS는 이런 schedule만 허용해야함

 

cascading rollback

- 하나의 transaction이 rollback하면 의존성이 있는 다른 transaction도 rollback 해야함

- 여러 transaction의 rollback이 연쇄적으로 일어나면 처리하는 비용이 많이 듦

 

해결책..!

데이터를 write한 transaction이 commit/rollback 한 뒤에 데이터를 읽는 schedule만 허용하자!

 

cascadeless schedule (avoid cascading rollback)

- schedule 내에서 어떤(any) transaction도 commit 되지 않은 transaction들이 write한 데이터는 읽지 않는 경우

하지만 이 경우에도 문제점이 없는 것은 아님

 

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

cascadeless schedule 문제점 예시

commit 되지 않은 transaction이 write한 데이터는 read하지 않아서 cascadeless schedule을 만족하지만, rollback을 하게 되면 transaction2번의 결과는 사라지고 피자 가격은 다시 3만원으로 돌아가게 됨.

 

 

해결책..!

strict schedule (가장 엄격한 스케줄)

- schedule 내에서 어떤 transaction도 commit 되지 않은 transaction들이 write한 데이터는 쓰지도 읽지도 않는 경우

- rollback 할 때 recovery가 쉬움

- transaction 이전 상태로 돌려놓기만 하면 됨

strict schedule로 바꿨을 때

 

concurrency control provides serializability & recoverability

이와 관련된 transaction의 속성은 Isolation

 

 

 

 

 

출처 : https://www.youtube.com/watch?v=89TZbhmo8zk&list=PLcXyemr8ZeoREWGhhZi5FZs6cvymjIBVe&index=16