Concurrency control

목적

• 동시에 실행되는 트랜잭션 제어
• 데이터베이스의 일관성 유지

없을 시 생기는 문제점

Lost Update

다른 세션의 트랜잭션이 수정한 데이터를 읽어와 해당 값을 다시 쓰는 경우, 다른 트랜잭션이 수정한 정보가 반영되지 않고 이전에 읽어온 값에만 수정이 이루어져 다른 트랜잭션이 수정한 정보가 누락될 수 있습니다.

Dirty Read

(=Uncommitted Dependency)

아직 commit되지 않았고 다른 세션의 트랜잭션이 변경한 데이터를 읽어오는 경우, 해당 세션의 트랜잭션이 rollback되면 문제가 발생할 수 있습니다.

Non-repeatable Read

(= Inconsistency)

한 세션의 트랜잭션이 데이터를 읽은 후, 다른 세션의 트랜잭션이 해당 데이터를 갱신하거나 삭제하고 commit한 경우, 원래 트랜잭션이 다시 해당 데이터를 읽어오면 처음에 읽어온 값과 새로 읽어온 값이 다를 수 있는 문제가 발생할 수 있습니다.

Phantom Read

한 세션의 트랜잭션이 검색 조건을 만족하는 데이터의 집합을 읽어오고, 다른 세션의 트랜잭션이 해당 검색 조건을 충족하는 데이터를 삽입한 경우, 원래 트랜잭션이 다시 검색을 하면 처음에 읽어온 값과 새로 읽어온 값이 다를 수 있는 문제가 발생할 수 있습니다.

SQL의 트랜잭션 격리 수준

밑으로 내려갈 수록 Isolation level이 커져, 안전하지만 다른 트랜잭션을 기다려야 하므로 성능은 떨어지게 됩니다.

Oracle

• READ COMMITTED와 SERIALIZABLE만 허용
• Default: READ COMMITTED

만약 사용자가 아직 commit되지 않은 행(locked row)을 읽으려고 한다면, 해당 데이터를 우회하여 Undo segment(commit되기 이전의 데이터)를 읽어옵니다. 따라서 트랜잭션이 커밋되기를 기다리지 않고도 SELECT 할 수 있게 됩니다.

MySQL

• Default: REPEATABLE READ

동시성 제어 종류

serializability 정리 글

Locking

• 데이터에 대한 액세스 권한
• Lock을 가지고 있는 트랜잭션만이 데이터 액세스 가능

Lock Modes

• Shared (S) Lock: 데이터를 read할 때 사용
• Exclusive (X) Lock: 데이터를 write할 때 사용

Locking Rule

Lock을 획득하는 시점

• Lock이 해제될 때까지 대기 ← Deadlock 발생 가능
• 여러 트랜잭션들이 대기 중일 때 ← Starvation 발생 가능

Lock을 해제하는 시점 (Unlock)

2 Phase Locking

Unlock을 한 후로는 Lock 요청 불가

기존 로킹 규약의 문제를 해결하고 트랜잭션의 직렬 가능성을 보장하기 위해 lock과 unlock 연산의 수행 시점에 대한 새로운 규약을 추가한 기법

단계

1. Growing Phase: Lock을 요청하는 단계
2. Shrinking Phase: Unlock 단계

Pros

• 2PL은 conflict serializability를 보장

Cons

• Deadlock 가능성 존재
• cascading rollback의 가능성 존재

Conservative 2PL

→ 트랜잭션 종료 단계에서 모든 Lock을 해제

Multiple Granularity Locking

MGL 정리글

Timestamp Ordering

• 트랜잭션과 데이터에 타임 스탬프를 할당
• 트랜잭션의 타임 스탬프 순으로 데이터를 액세스
• 순서를 만족하지 못하는 경우, 트랜잭션 철회

Optimistic control

• 트랜잭션의 충돌이 없다고 가정

  • local 데이터에 대해 트랜잭션 실행 후, 검증
  • 검증의 결과를 확인했는데 충돌이 발생했다면 rollback
  • 충돌이 발생하지 않은 경우, 해당 실행 결과를 저장

• 대부분의 트랜잭션의 read-only이고 쓰기가 드문 경우, 좋은 선택

참조

https://gateoverflow.in/223561/self-doubt

2PL 단계 이미지