- MySQL 문법을 기준으로 서술한다.
unrecoverable schedule
- schedule 내에서 commit된 transaction이 rollback된 transaction이 write 했었던 데이터를 읽은 경우
- 이러한 경우는 rollback을 해도 이전 상태로 회복 불가능할 수 있기 때문에 이런 schedule은 DBMS가 허용하면 안된다.
그러면 어떤 schedule이 recoverable한가?(recoverable schedule)
- schedule 내에서 어떤 transaction도 자신이 읽은 데이터를 write한 transaction이 먼저 commit/rollback 전까지는 commit하지 않는 경우
- 하나의 transaction이 rollback하면 의존성이 있는 다른 transaction도 rollback해야 한다.(Cascading rollback)
- 여러 transaction의 rollback이 연쇄적으로 일어나면 처리하는 비용이 많이 든다.
- 이러한 비용 문제를 해결하기 위해 데이터를 write한 transaction이 commit/rollback한 뒤에 데이터를 읽는 schedule만 허용하자.
- 즉, schedule 내에서 어떤(any) transaction도 commit 되지 않은 transaction들이 write한 데이터는 읽지 않는 경우(cascadeless schedule 또는 avoid cascading rollback)
- 이러한 방식도 모든 scheduling 문제릃 해결하는 것은 아니다.
- read 행위를 하지 않고 write을 하는 transaction 두 개가 서로 겹쳐서 실행될 때의 문제는 해결 못함.
- strict schedule : schedule 내에서 어떤 transaction도 commit되지 않은 transaction들이 write 한 데이터는 쓰지도 읽지도 않는 경우
- rollback을 할 때 recovery가 쉽다.
- transaction 이전 상태로 돌려놓기만 하면 된다.