동시성 제어를 공부하기 전 먼저 스케줄에 대해 알아봅시다.
이 전에 공부했던 트랜잭션 성질 중 Isolation을 공부하면서 나왔던 예제의 연장선입니다.
K가 H에게 20만원을 입금하는 과정 동시에 H는 자신의 계좌에 30만원을 입금하려합니다.
위와 같이 발생할 수 있는 상황 4가지를 모두 표현하면 아래와 같습니다.
r은 read
w는 write
1,2 숫자는 트랜잭션
(K),(H)는 읽으려는 데이터를 의미합니다.
1. Schedule
여러 트랜잭션들이 동시에 실행될 때 각 트랜잭션에 속한 operations의 실행 순서를 말합니다.
여기서 각 트랜잭션 내의 operations의 순서는 바뀌지 않습니다.
즉 아래 그림에서 case4의 스케줄은 r1(k)-w1(k)-r1(H)-...-w1(H)-c1 입니다.
1.1 Serial schedule
한번에 한개의 트랜잭션이 실행되는 스케줄이며
-> 트랜잭션이 꼬이지는 않으나 성능이 좋지 않습니다.
case1과 case2에 해당합니다.
1.2 Nonserial schedule
트랜잭션들이 겹쳐서 실행되기 때문에 동시성이 높아져서 같은 시간동안 더 많은 트랜잭션들을 처리할 수 있습니다.
-> 어떤 형태로 트랜잭션이 겹치냐에 따라 이상한 결과가 나올 수 있습니다.
case3과 case4에 해당합니다.
2. 최적의 방법
성능이 좋은 Nonserial schedule로 하고 싶지만 이상한 결과가 나오는 건 싫을 때
어떻게 해야할까요?
-> serial schedule과 동일한 nonserial schedule을 실행하도록 하면 됩니다.
스케줄이 동일하다?
스케줄이 동일하다는 건 두 스케줄 간에 conflict equivalent 일 때 스케줄이 동일하다고 합니다.
그러면 conflict는 무엇이고 conflict equivalent는 무엇일까요?
conflict
- 서로 다른 트랜잭션 소속
- 같은 데이터에 접근
- 최소 하나는 쓰기 명령
을 모두 만족할 때 conflict 라고 합니다.
conflict equivalent
- 두 스케줄은 같은 트랜젝션들을 가지고
- 어떤 conflicting operations의 순서도 양쪽 스케줄 모두 동일할 때
conflict equivalent 하다고 합니다.
아래 그림을 보시면
sched.3에서 r1(K) -> w1(K), r2(H) -> w2(H), r1(H) ->w1(H) 의 순서가
sched.2에서도 똑같은 방향을 보고 있습니다.
serial schedule과 conflict equivalent 할 때 이를 conflict serializatble 이라고 합니다.
즉 sched.3(nonserial schedule)은 sched.2(serial schedule)과 conflict equivalent 하기때문에
sched.3은 conflict equivalent 입니다.
3. 정리
스케줄이 다른 하나의 serial 스케줄과 equivalent하다면 이는 serializable 하다고 합니다.
스케줄이 다른 하나의 serial 스케줄과 conflict equivalent하다면 이는 conflict serializable 하다고 합니다.
우리는 conflict serializable 한 스케줄만 사용하기 위해서
여러 트랜잭션을 동시에 실행해도 스케줄이 conflict serializable 하도록 보장하는 프로토콜을 적용시킵니다.
어떤 스케줄도 serializable하도록 만들어주는 프로토콜을 동시성 제어(concurrency control)라고 합니다.
4. unrecoverable schedule
스케줄 내에서 commit된 트랜잭션이 rollback된 트랜잭션이 write 했던 데이터를 읽은 경우를 말합니다.
K는 H가 입금한 금액을 읽고 입금을 완료한 상태에서 commit까지 했기 때문에 Durability에 의해 commit된 데이터는 되돌릴 수가 없습니다.
이런 경우는 rollback을 해도 이전 상태로 회복이 불가능할 수 있기 때문에 이런 스케줄은 DBMS가 허용해서는 안됩니다.
회복 불가능한 스케줄이 아니라 회복 가능한 스케줄을 사용해야합니다.
5. recoverable schedule
이를 해결하기 위해서는 스케줄 내에서 그 어떤 트랜잭션도 자신이 읽은 데이터를 write한 트랜잭션이 먼저 commit,rollback 하기 전까지는 commit을 하지 않아야 합니다.
이러한 스케줄을 recoverable schedule이라고 합니다.
즉 자신이 참조한 데이터가 모두 commit, rollback이 되고 나서 자신의 데이터도 commit, rollback을 해야 합니다.
문제점
하지만 이렇듯 의존하는 데이터를 따라 cascading rollback을 하게되면 처리 비용이 많이 들게 됩니다.
이를 해결하기 위해서 고안한 방법이 데이터를 write한 트랜잭션이 commit, rollback한 뒤에 데이터를 읽는 스케줄만 허용하는 것입니다.
commit,rollback하기 전에 미리 데이터를 읽고 결과에 따라 가기보다는 트랜잭션이 종료된 후에 데이터를 읽는 것입니다.
이러한 스케줄을 cascadeless schedule이라고 합니다.
cascadeless schedule 또 문제점
이런 방식도 여전히 문제점은 존재합니다.
가격을 읽는 것 뿐만 아니라 쓸 때도 동일한 오류가 발생합니다.
이를 해결하기 위해 스케줄 내에서 어떤 트랜젝션도 commit되지 않은 트랜잭션이 쓴 데이터는 읽지도 쓰지도 않아야 합니다.
이러한 스케줄을 strict schedule이라고 합니다.
정리
동시성 제어란 이런 Serializability와 recoverability를 모두 만족하며 이와 관련된 속성이 Isolation입니다.
