DB Transaction & Concurreny Control (2)
❒ Description
트랜잭션은 ACID라는 속성을 가진다. 그 중 A는 Atomicity, 원자성을 의미한다. 원자성을 보장하기 위해서
commit과 rollback이 존재한다. 오늘은 트랜잭션들이 동시에 시작될 때 rollback이 발생하면 어떤 일들이
벌어지는지 알아보자.
❒ Concurrency Control : recoverability
1. Unrecovarable Schedule
위 그림에서 Tx2는 chul_money를 2000에서 5000으로 update를 해주었기 때문에 Rollback이 발생할
경우 다시 2000으로 돌려놔야 한다. 이렇게 되면 Tx2는 더 이상 유효한 작업이 아니게 된다.
따라서 Tx2에서 write 했던 chul_money를 읽은 tx1도 롤백을 해줘야 Atomacity를 보장할 수 있다.
하지만 Tx1은 이미 commit이 된 상태이므로 Duablitiy(지속성, 영속성) 때문에 rollback을 할 수 없다.
이렇게 하나의 schedule 내에서 commit된 트랜잭션이 rollback된 트랜잭션이 write 했었던 데이터를 읽는
경우를 Unrecoverable Schedule이라고 한다. 이런 schedule은 rollback을 해도 Atomicity가 보장되지
않기 때문에 DBMS에서 허용하지 않는다.
2. Recoverable Schedule
Schedule 내에서 그 어떤 트랜잭션도 자신(Tx1)이 읽은 데이터를 write한 트랜잭션(Tx2)이 먼저 commit 또는
rollback 전까지는 commit 하지 않는 경우를 Recoverable Schedule이라고 한다. 이런 상태의 schedule은
rollback을 할 때 Atomacity를 보장할 수 있기 때문에 DBMS에서는 이런 schedule을 허용한다.
위 그림에서 TX1은 TX2에 의존하고 있다. 이와 같이 하나의 트랜잭션이 rollback하면 의존성이 있는
다른 트랜잭션도 rollback되어야 한다. 이것을 Cascading rollback이라고 한다.
3. Casecadeless Schedule
Cascading rollback은 연관된 모든 트랜잭션에 대해서 rollback을 수행해야 하기 때문에 그 비용이 많이
발생한다. 이 문제를 해결하기 위해 Casecadeless Schedule이 등장한다.
Casecadeless Schedule이란 schedule 내에서 그 어떤 트랜잭션도 commit 되지 않은 트랜잭션들이
write한 데이터는 읽지 않는 경우를 말한다. avoid cascading rollback이라고 부르기도 한다.
4. Strict Schedule
Strickt Schedule은 방금 봤던 Cascadeless Schedule 보다 더 엄격한? schdule로, schedule 내에서 그 어떤
트랜잭션도 commit 되지 않은 트랜잭션들이 write한 데이터는 쓰지도, 읽지도 않는 경우를 말한다.
위 예제는 Cascadeless Schedule은 맞지만, Strick Schedule이 아니다.
왜냐면 Tx2가 commit 되지 않은 트랜잭션 Tx1이 write한 데이터를 다시 write하고 있기 때문이다.
따라서 다음과 같이 예제를 수정하면 Strick Schedule을 만족하게 된다.
Strick Schedule은 rollback할 때 recovery가 쉽다. 단지 트랜잭션을 이전 상태로 돌려놓기만 하면 되기 때문이다.
❒ 정리
지금까지 학습했던 Schedule들은 위와 같이 표현할 수 있다.
다시 복습하자면, Recovarable Schedule이란 자신이 read한 데이터를 write한 트랜잭션이 먼저 commit 또는
rollback 하기 전까지는 commit을 하지 않는 Schedule을 의미한다.
이렇게 Concurrency Control은 serializability와 recovarability를 갖도록 보장해주는 역할을 하며,
isolation 속성과 밀접한 관계를 갖는다.