[DB] SQL 표준 DB transaction isolation(격리수준) 개념

# 트랜잭션 격리수준 4 단계

 

---

1. READ_UNCOMMITED 

• DB에 커밋되지 않은 데이터를 읽을 수 있다.
• Dirty Read 로 인해 데이터 정합성에 심각하게 문제를 야기하므로, 실제 서비스에서 거의 쓰이지 않는다.

 # Dirty Read

• READ_UNCOMMITED 상태에서 발생
• 먼저 발생한 트랜잭션의 데이터를 참조하는 현상

 (예시)  

1. A 트랜잭션에서 1번 사원의 직급을 Junior 에서 Senior 로 바꿈 

2. B 트랜잭션에서 1번 사원을 조회하고, 연봉을 2800에서 3000으로 수정함

3. A 트랜잭션 ROLLBACK 

4. B 트랜잭션 COMMIT 

5. 1번사원은 결국 직급이 Senior, 연봉이 3000 인 데이터로 변경

---

2. READ_COMMITED

• 커밋된 데이터만 읽는다.
• Dirty Read 현상을 해결
• UNREPEATABLE READ 현상 야기
• 해당 격리수준에서 SQL문이 어떠한 결과를 초래할지 정확히 예측하고 있어야 한다.

#  UNREPEATABLE READ

• 한 트랜잭션내에서 업데이트 하지 않고 반복적으로 조회만 했을 뿐인데, 값이 업데이트 되어 있는 현상

 (예시) 

1. A 트랜잭션에서 1번 플레이어 게임머니를 조회

2. B 트랜잭션에서 1번 플레이어 게임머니를 조회

3. A 트랜잭션에서 1번 플레이어 게임머니를 2800에서 3000으로 업데이트 시킨 후, COMMIT

4. B 트랜잭션에서 1번 플레이어 게임머니를 조회 (커밋된 데이터만 읽기 때문에 업데이트 된 데이터가 조회됨)

---

3. REPEATABLE_READ

• 스냅샷을 이용하여, 트랜잭션 내에서 반복적으로 값을 조회하더라도 동일한 값을 리턴해주게 보장함
• UNREPEATABLE READ 현상 해결
• PHANTOM READ 현상 야기

# 스냅샷(Snap shot)

• 트랜잭션이 시작되기 전에 커밋된 내용을 사진찍듯이 정보를 가지고 있는 것

# PHANTOM READ

• 없던 데이터가 보이는 현상
• 없던 데이터가 업데이트되거나, 삭제되거나... 등등..

 (예시) 

1. B트랜잭션에서 '음료 테이블' 조회 (음료메뉴가 모두 커피종류 였으나, 차 종류를 추가하기로 결정!)

2. A트랜잭션에서 '음료 테이블'에 '녹차' 추가 후 커밋

3. B트랜잭션에서 '음료 테이블'을 '커피 테이블'로 변경 후 커밋

4. '녹차'가 포함된 '음료테이블'이 '커피 테이블'로 변경

---

4. SERIALIZABLE

• 커밋이 일어나지 않은 트랜잭션이 존재한다면, 다른 트랜잭션은 시작조차 하지 못하게 함
• PHANTOM READ 현상 해결
• 기다리는 시간이 길어질 수 있어, 성능은 좋지 못함
• READ_UNCOMMITED 와 같이 실제 서비스에 거의 쓰이지 않음.