Lost Update 현상
여러 트랙잭션이 동시에 같은 데이터를 수정하려고 할때 발생할 수 있는 현상으로, 기존에 update 되어야 하는 트랜잭션 연산이 다른 트랜잭션의 update를 통해 덮어쓰여지는 현상.
| Kim 계좌 | Lee 계좌 | |
|---|---|---|
| Transaction 1 ( kim → lee : +20) | read(kim) ⇒ 100 만원 | |
| write(kim = 80 만원) | ||
| read(lee) ⇒ 200 만원 | ||
| Transaction 2 (lee(현금) → lee(계좌 : +30) | read(lee) ⇒ 200 만원 | |
| write(lee) ⇒ 230 만원 → commit | ||
| Transaction 1 ( kim → lee : +20) | write(lee) ⇒ 220 만원 → commit |
Schedule, Serial Schedule, NonSerial
Schedule
- 여러 트랜잭션들이 동시에 실행될때, 각 트랜잭션에 속한 operation들의 실행 순서
Serial Schedule
- 트랜잭션들이 겹치지 않고 한 트랜잭션의 commit 후 다른 트랜잭션의 연산을 하는 실행순서
- 위 그림의 schedule 1, schedule 2에 해당한다.
- 한번에 하나의 트랜잭션만 실행하기에 좋은 성능을 낼 수 없지만, Isolation을 무조건 보장
- 하지만 성능이 낮기에 현실적으로 사용할 수 없는 방식
NonSerial Schedule
- 트랜잭션들이 겹쳐서 실행되는 실행순서
- 위 그림의 schedule 3, schedule 4에 해당한다.
- 한번에 여러 트랜잭션을 실행하기에 비교적 좋은 성능을 내지만, Isolation을 무조건 보장하지 못하고 Lost Update 현상과 같은 이상한 결과를 만들 수 있다
- 좋은 성능을 위해 NonSerial Schedule을 사용하지만, 이상한 결과를 막고자 함 ⇒ Serial Schedule과 동일한(equivalent) NonSerial Schedule을 실행!! ⇒ 그 중 하나의 개념인 conflict serializable
conflict serializable
Conflict of two operations
아래 세가지 조건을 모두 만족하면 conflict.
- 서로 다른 트랜잭션 소속
- 같은 데이터에 접근
- 최소 하나는 write operation
conflict operation은 순서가 바뀌면 결과도 바뀜. 위 schedule 3의 read-write operation의 순서를 바꾸면 schedule 4가 되는데 그러면 Lost Update 현상이 일어나 결과가 이상하게 됨.
Conflict equivalent for two schedules
아래 두조건을 만족하면 Conflict equivalent 라고 함
- 두 schedule은 같은 트랜잭션들을 가진다
- 어떤 conflicting operations의 순서도 양쪽 schedule 모두 동일하다
Conflict Serializable
아래 schedule 3은 serial schedule인 schedule 2와 conflct equivalent 하다. 따라서 Conflict of two operations가 존재하지만, 이상한 결과없이 연산을 수행.
serial schedule과 conflict equivalent일 때, Conflict Serializable 하다고 함.
즉 schedule 3은 Conflict Serializable 하다고 함. schedule 4는 Conflict Serializable 하지 않음. ← serial schedule인 schedule1, 2와 모두 실행 순서가 동일하지 않음
Conflict Serializable Protocol
실제로 Conflict of two operations이 발생하는 경우, 이를 모든 serial schedule가 비교하며 Conflict Serializable한지 아닌지 체크하지는 않음 ← 비용이 많이 들기에
여러 트랜잭션을 동시에 실행해도 schedule이 conflict Serializable 하도록 보장하는 프로토콜을 적용
