728x90
반응형
Transaction 1은 K가 H에게 송금하는 트랜잭션이고, Transaction 2는 H가 자신에게 30만원 입금하는 트랜잭션이다.
- Transaction1에서 read를 통해 K의 계좌를 read해서 확인하고, write해서 20만원을 차감한다.
- 이때 Transaction2에서 H의 계좌를 read로 확인하고 write해서 30만원을 더해준다.
- Transaction1은 H의 계좌를 read로 확인하고 20만원 송금 write를 하고 Transaction1은 commit을 한다.
- 이때 Transaction2에서 abort가 일어나 롤백이 된다. 그래서 다시 H의 계좌를 230에서 200으로 돌려놓는다.
- 트랜잭션 2는 더 이상 유효하지 않으므로 트랜잭션2가 write했던 H_balance를 읽은 트랜잭션 1도 rollback 해야된다.
- 그러나 트랜잭션 1번은 이미 commit된 상태이므로 durability 속성 때문에 rollback할 수 없다.
- 결국 트랜잭션 1번은 유효하지 않은 데이터를 읽어서 작업을 한 셈이다. 데이터 불일치 발생
위의 예시와 같이 schedule 내에서 commit된 transaction이 rollback된 transaction이 write했었던 데이터를 읽은 경우를
unrecoverable schedule이라고 한다.
rollback을 해도 이전 상태로 회복 불가능할 수 있기 때문에 이런 schedule은 DBMS가 허용하면 안된다.
- 1번 트랜잭션이 2번트랜잭션이 write한것을 읽기 때문에 1번 트랜잭션은 2번 트랜잭션을 의존하고 있다.
- 그래서 2번 트랙잭션을 먼저 commit하거나 rollback하고 그다음에 1번 트랜잭션을 commit하거나 rollback해야한다.
- 결론은 의존성이 있을때는 의존성의 대상이 되는 트랜잭션이 종료될 때까지 의존하는 트랜잭션은 종료하면 안된다.
- 해당 schedule을 recoverable schedule이라고 한다.
- rollback할 때 이전 상태로 온전히 돌아갈 수 있기 때문에 DBMS는 이런 schedule만 허용해야 한다.
cascading rollback
- 하나의 트랜잭션이 rollback하면 의존성이 있는 다른 트랜잭션도 rollback해야 한다.
- 비용이 많이 든다.
- 데이터를 write한 transaction이 commit/rollback 한 뒤에 데이터를 읽는 schedule만 허용하자!
- 위의 장점은 만약 트랜잭션 2번이 문제가 생겨서 롤백을 하게 되어도 트랜잭션 2번의 write를 의존하는 트랜잭션이 없기 때문에 트랜잭션 2번만 롤백하면 된다.
cascadeless schedule
- schedule 내에서 어떤 트랜잭션도 commit 되지 않은 트랜잭션들이 write한 데이터는 읽지 않는 경우
그러나 만약 H 사장님이 3만원이던 피자 가격을 2만원으로 낮추려는데, K직원도 동일한 피자의 가격을 실수로 1만원으로 낮추려 했을때 이런 schedule도 생길 수 있다.
- K직원이 피자 가격을 1만원으로 바꾼다.(트랜잭션 1번)
- H사장이 피자 가격을 2만원으로 바꾸고 commit한다.(트랜잭션 2번)
- 이때 트랜잭션 1번이 롤백되어 피자 가격이 3만원이 되어버린다.
- 즉, 트랜잭션 2번 결과가 사라졌다.
- 이는 cascadeless schedule인데 문제점이 있는 것이다.
위의 문제를 해결할 방법은 strict schedule이다.
strict schedule
- schedule 내에서 어떤 트랜잭션도 commit되지 않은 트랜잭션들이 write한 데이터는 쓰지도 읽지도 않는 경우
- 트랜잭션 1번에서 피자의 가격 1만원으로 하고 얘가 commit이 되든 abort가 되든 트랜잭션 1번이 종료되어야 한다.
- 그리고나서 트랜잭션 2번을 실행하면 된다.
- strict schedule의 장점은 rollback할 때 recovery가 쉽다 트랜잭션 이전상태로 돌려놓기만 하면 된다.
728x90
반응형
