[MySQL] concurrency control 기초2 (recoverability)

참고 자료 

유투브 쉬운코드 동시성 제어

 

예제

schedule 개념과 serializability에 대한 개념이 없으면 이전 글을 참고하자 

https://20240228.tistory.com/407

[MySQL] concurrency control 기초1 (schedule, serializability)

 

트랜잭션1 K가 H에게 20만원 입금  

트랜잭션2 H가 자신 계좌에 30만원 입금 

 

트랜잭션1 commit 이후 트랜잭션2가 rollback 하면서 20만원이 증발했다.

 

schedule 내에서 commit된 트랜잭션이 롤백된 트랜잭션이 write 했었던 데이터를 읽는 경우 

이런 케이스를 unrecoverable schedule 이라고 한다. 

 

unrecoverable schedule은 rollback 해도 이전 상태로 회복 불가능할 수 있기 때문에 

이런 schedule은 DBMS가 허용하면 안된다 

어떤 schedule이 recoverablity 한가?

 

트랜잭션1은 트랜잭션2에 의존성이 있다. 

같은 H의 계좌에 대해서 작업을 하기 때문이다.

이럴때 트랜잭션1은 의존성이 있는 트랜잭션2가 commit / rollback 하기 전까지 commit / rollback 작업을 하면 안 된다. 

트랜잭션2가 먼저 commit 하면 같이 commit 하고 트랜잭션2가 rollback 하면 같이 rollback 해야 한다. 

 

recoverable schedule 

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

DBMS는 이런 recoverable 한 schedule만 허용해야 한다. 

 

cascading rollback

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

여러 트랜잭션이 rollback이 연쇄적으로 일어나면 처리하는 비용이 많이 든다 

 

cascadeless schedule (avoid cascading rollback)

schedule 내에서 어떤 트랜잭션도 commit 되지 않은 트랜잭션이 write 한 데이터는 읽지 않은 경우 

이렇게 하면 트랜잭션1이 트랜잭션2에 대한 의존성이 사라진다. 

cascadeless schedule 문제점 

H사장님이 3만원이던 피자를 2만원으로 낮추려는데

K직원도 동일한 피자의 가격을 실수로 1만원으로 낮추려 했을 때

피자 가격이 최종적으로 3만원이 되었다. 즉 트랜잭션2의 작업이 날라갔다. 

현재 schedule은 cascadeless schedule 이다. 

트랜잭션 내에서 커밋 되지 않은 데이터의 읽기를 금지하는 게 해당 스케줄인데 

현재 작업에는 읽기 작업이 없기 때문에 가능하다. 

 

이를 막으려면 좀 더 엄격한 스케줄이 필요하다.

 

strict schedule 

schedule 내에서 어떤 트랜잭션도 commit 되지 않은 트랜잭션이 write한 데이터는 쓰지도 읽지도 않는 경우 

rollback 할 때 recovery가 쉽다 

트랜잭션 이전 상태로 돌려놓기만 하면 된다