[Transaction] Recoverability

serializability를 확인하는 이유는 database의 consistency를 concurrent execution 하에서 보장하기 위함이었다.

transaction 수행시 failure 발생할 때 회복 가능하도록 하는 것과 관련되어 살펴보겠다.

 

RC

database의 consistency를 위해서는 스케줄이 recoverable해야한다. 

 

recoverable schedule의 핵심은 commit의 순서를 규칙에 따라 조정하는 것이다. 규칙은 서로 다른 트랜잭션이 같은 데이터를 read와 write 하면 read하는 트랜잭션을 더 늦게 commit하는 것이다. 아래와 같이 처리하는 것이다.

Tj                     Ti

W(x)

                      R(x)

commit

                     commit

 

cascading rollback: 하나의 트랜잭션에 failure가 발생하면 영향을 받는 다른 트랜잭션들이 연쇄적으로 롤백된다. 이런 것은 undo 작업을 해야하는데 부하가 막대하다. 따라서 cascadeless schedule이 필요하다.

 

cascadeless schedule(ACA)

Ti(Write(Q)) -->Tj(Read(Q)) 라면 다음과 같이 하는 것이다.

Ti(Write(Q)) -->commit-->Tj(Read(Q)) 

 

Tj                     Ti

W(x)

commit

                      R(x)

 

                     

 

이렇게 하면 failure가 언제 발생하던지 cascade rollback을 유발하지 않는다. 즉, commit 된 값 만을 read를 하게 되는 것이다. 위 방식을 사용하면 recoverable하다. 

 

따라서, 비용이 큰 cascade rollback을 피하게 되었다.

 

cascadeless 보다 엄격한 방법을 살펴보자.(ST)

Oi[x] : Read/Write 연산

Wj[x] ---> Oi[x] 이라면 Tj의 abort --> Oi[x] 이거나 Tj의 commit ---> Oi[x] 이어야 한다.

쉽게 얘기하면 T2에서 데이터X를 Read/Write를 하기 전에 T1에서 (write(X)+commit)이나 (write(X)+abort)를 해야한다는 것이다.  

 

Tj                     Ti

W(x)

commit/abort

                      R(x)/W(x)

                      commit

 

 

schdule

우리가 Serializable한 스케줄을 구한 것이 SR이다. 이 스케줄은 회복가능하지 않을 수도 있다. RC에서 엄격한 ST까지 가면 concerrecy를 떨어뜨릴 수도 있다. 따라서, database system에서는 SR이면서 RC스케줄이나 ACA 스케줄 정도를 실행을 해야한다.