개요
해당 글은 쉬운코드님의 https://www.youtube.com/watch?v=0PScmeO3Fig&t=31s 를 시청하고 개인적으로 정리한 글입니다 :)
쓰기 락 (베타 락)
- read/write 할 때 사용한다
- 다른 트랜잭션이 데이터를 read/write 하는 것을 허용하지 않는다.
데이터베이스에서 값을 변경하는 작업은 단순히 값 하나 바꾸는 것보다 더 복잡한 과정을 거친다 (인덱스 테이블 갱신, 파일 입출력), 같은 데이터에 read/write 가 발생하면 예상치 못한 동작을 할 수 있다.
읽기 락 (공유 락)
- read 할 때 사용한다
- 다른 트랜잭션이 같은 데이터를 읽는 것을 허용한다
락을 사용해도 이상한 결과가 반환될 수 있을때
(x=100, y=200) 이란 데이터베이스가 존재할때 서로 다른 두개의 트랜잭션이 아래와 같은 연산을 수행한다고 가정하자
- ts1: x와 y의 합을 x 에 저장
- ts2: x와 y의 합을 y 에 저장
위 두개의 연산으로 트랜잭션을 실행할 때의 결과값은 아래와 같이 여러개가 존재할 수 있다.
- ts1 => ts2 순차적으로 실행 될 경우 결과값: x = 300, y = 500
- ts2 => ts1 순차적으로 실행 될 경우 결과값: x = 400, y = 300
- ts1, ts2 가 순서가 보장되지 않고 실행될 경우의 가능한 결과값: x = 300, y = 300
이와 같은 불일치 문제는 먼저 실행된 트랜잭션이 자원에 대한 쓰기 락을 취득하기전 이후에 실행되는 트랜잭션이 읽기 락을 취득하면서 발생한다.
해결방법
- 2PL protocol 사용
2PL protocol
트랜잭션에서 모든 locking operation 이 최초의 unlock operation 보다 먼저 수행되도록 하는 것 (2PL(two-phase-locking protocol), Serializbilty 를 보장한다.
하지만 상황에 따라서 데드락이 발생할 수 있다.
- Expanding phase (growing phase): lock 을 취득하기만 하고 반환하지는 않는 phase
- Shrinking phase (contracting phase): lock 을 반환만하고 취득하지는 않는 phase
Conservative 2PL
모든 lock 을 취득한뒤 transaction 을 시작
- dead-lock free
- 실용적이진 않음
Strict 2PL (S2PL)
- strict schedule 을 보장하는 2PL
- recoverability 보장
- write-lock 을 commit/rollback 될 때 반환
strong strict 2PL (SS2PL)
- read-lock / write-lock 모두 commit / rollback 될 때 반환
- S2PL 보다 구현이 쉬움
- 하지만 성능은 좋지 않다
단점
- read-read 를 제외하고는 전부 연산이 block 되어서 전체 처리량이 좋지 않다
해결 방법
- read 와 write 가 서로를 block 하는 것만 해결해보자 해서 나온게 MVCC
'데이터베이스' 카테고리의 다른 글
[MongoDB] - MongoDB Replicaset (0) | 2024.01.10 |
---|---|
[데이터베이스] - DBCP(Database Connection Pool) (0) | 2024.01.10 |
[데이터베이스] - 트랜잭션 동시성 제어 (2) (1) | 2024.01.04 |
[데이터베이스] - 트랜잭션 동시성 제어 (1) (0) | 2024.01.04 |
[데이터베이스] - 최적화 방법 11가지 (1) | 2024.01.02 |