트랜잭션 동시성 오류와 고립수준

Transaction Concurrency Anomaly

트랜젝션이 번갈아 가면서 수행되지 않고, 요청한 순서대로 수행되는 것을 serializable 스케줄이라고 한다. 트랜젝션이 번갈아 가면서 수행되면 unserializable해질 수 있는데 이 때문에 4가지 (3+1) 동시성 문제가 생길 수 있다. 1~3 번 문제는 트랜잭션이 Read, Write연산만 있다고 가정했을때 생길 수 있는 문제이고, 4번 문제는 Update, Delete 연산까지 있다고 생각했을 때 생길 수 있는 문제이다.

1. Dirty Read

위 스케줄에서 T1이 R(A)를 하고, T1이 W(A)를 한 뒤, T2가 R(A)를 하게 되는데, T2, T1이 직렬적으로 수행되는 스케줄과 비교하면 이는 틀린 결과를 가지게 된다. 즉 committed 하지 않은 트랜잭션이 쓴 값을 읽는 것을 Dirty Read 라고 한다.

2. Unrepeatable Read

위 스케줄에서 T2가 읽고 T1이 쓴 값을 T2가 다시 읽으면 처음 읽은 값과 두 번째 읽은 값이 다르게 된다. 한 트랜잭션에서 그 트랜잭션이 write연산을 수행하지 않음에도, 처음 읽은 값과 나중에 읽은 값이 다르게 되는 것을 Unrepeatable Read라고 한다.

3. Lost Update

위 스케줄에서 T1이 A에 값을 쓰고, T2가 다시 값을 쓰게되면 T1은 원래 자신이 쓴 값을 잃어버리게 된다. 이 처럼, write-write conflict에 의해 자신이 쓴 값을 잃어버리게 되는 것을 Lost Update라고 한다.

4. Phantom Read

이 문제는 transaction의 update, delete까지 고려하고, tuple lock 방식을 채택했을 때 생기는 현상이다.

T1이 Read 한 뒤 결과는 2 Rows 이다. T2가 새로운 row를 추가하고 commit한다. T1이 다시 읽었을 때, 원래의 값과 다르다. 서로 간 tuple의 충돌이 없었음에도 불구하고 결과가 serialize하지 않게 값이 읽히는 것을 phantom read라고 한다.

Transaction Isolation level

DBMS는 요구에 따라 완화된 트랜잭션 고립 수준을 제공한다. 고립수준에는 약한 순으로 Read Uncommitted, Read Committed, Repeatable Read, Serializable 이 있다. 모든 고립 수준에서 Long X-Lock을 제공한다고 할 때, 각 레벨은 다음과 같은 S-lock을 제공한다.

고립수준	Read Uncommitted	Read Committed	Repeatable Read	Serialize
S-Lock 상태	S-Lock이 없음	짧은 S-Lock (잠그고 읽고 바로 품)	긴 S-Lock (commit 전에 품)	긴 S-Lock (table lock)

아래의 표는 각 고립레벨에서 생길 수 있는 anomaly 현상이다 (Long X-Lock에서 update loss는 생기지 않는다).

Read phenomena Isolation level	Dirty reads	Non-repeatable reads	Phantoms
Read Uncommitted	-	-	-
Read Committed	+	-	-
Repeatable Read	+	+	-
Serializable	+	+	+

출처

https://www.gatevidyalay.com/concurrency-problems-in-transaction/
https://dotnettutorials.net/lesson/phantom-read-concurrency-problem-sql-server/
https://en.wikipedia.org/wiki/Isolation_(database_systems)