Transaction Isolation Level(트랜잭션 격리 수준)

Database Anomalies

1. Dirty read

- 다른 transaction에 의해 수정 됐지만 아직 commit 되지 않은 데이터를 읽는 것

ex) Transaction A가 새로운 row를 추가하고 Transaction B가 새로운 row를 읽었는데 A가 roll back을 한 경우

 

2. Nonrepeatable read

- 한 transaction 내에서 같은 row를 두 번 읽었는데 그 사이에 값이 변경되거나 삭제되어 결과가 다르게 나타나는 현상

ex) Transaction A가 row를 읽고 Transaction B가 그 row를 변경하고 A가 같은 row를 두 번째 읽었을 때 새로운 결괏값을 얻는 경우 

 

3. Phantom read

한 transaction 내에서 같은 쿼리를 두 번 실행했는데, 첫번째 쿼리에서 없던 유령 record가 두 번째 쿼리에서 나타나는 현상

ex) Transaction A가 WHERE 절에 해당하는 모든 row를 읽어들이고 Transaction B가 WHERE 절을 만족하는 추가적인 row를 insert 한 후 A가 WHERE 절을 다시 검색했을 때 additional 한 row가 추가되는 경우

 

+ 4. serialization anomaly

The result of successfully committing a group of transactions is inconsistent with all possible orderings of running those transactions one at a time(한 번에 하나씩).

 

 

---

 

Transaction Isolation Level 4단계

1. READ UNCOMMITTED

- uncommitted 된 변화도 transaction은 다 볼 수 있음.

- 모든 database anomalies 다 발생 가능함.

 

2. READ COMMITTED

- transaction이 committed되기 전까지 transaction 내에서 일어난 변화는 외부에 관찰되지 않음. 

- dirty read 방지

 

3. REPEATABLE READ

- read 는 lock을 획득한 row들은 그 transaction이 완전히 끝나기 전까지는 다른 transaction이 그 row들을 수정하지 못하도록 하는 것. 

- phantom read, serialization anomaly는 여전히 발생 가능

ex) InnoDB의 default isolation level

 

4. SERIALIZABLE

- transaction을 위해 table들이 lock 되어서 WHERE 조건이 다른 transaction에 의해 값이 추가되거나 값이 제거되는 등 수정되지 않는 것.

- 가장 엄격한 격리 수준. 

- transaction들이 동시에 일어나지 않고, 하나씩 순서대로 실행되는 것처럼 작동

- 읽기 작업에도 lock을 설정하게 되고, 동시에 다른 transaction에서 이 record를 변경하지 못하게 됨

=> 동시 처리 능력이 다른 isolation level보다 떨어지고, 성능 저하가 발생

- 모든 database anomaly 방지 

 

 

https://www.postgresql.kr/docs/13/transaction-iso.html

 

 

 

 

Reference

• https://www.ibm.com/docs/en/i/7.3?topic=transactions-transaction-isolation-levels 
• https://www.postgresql.kr/docs/13/transaction-iso.html
• https://joont92.github.io/db/%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-%EA%B2%A9%EB%A6%AC-%EC%88%98%EC%A4%80-isolation-level/