Locking
식당에서 각 의자에는 한 사람만 앉아서 식사를 할 수 있다. 하지만 식당 내의 빈 공간은 빈 자리가 생길 때까지여러 손님들이함께 머무를 수 있다.
독점 락(exclusive lock)
트랜잭션에서 갱신을 목적으로 데이터 항목을 접근할 때
공유 락(shared lock)
트랜잭션에서 읽을 목적으로 데이터 항목을 접근할 때
공유 로크가 걸려있는 데이터 항목에 대해 독점로크를 요청하거나,
독점 로크가 걸려있는 항목에 대해 독점 로크나 공유 로크를 요청하는 경우에는 로크를 허용해서는 안 된다.
트랜잭션이 데이터 항목에 대한 접근을 끝낸 후에 lock을 해제한다.
Dead Lock
정의
여러 트랜잭션이 서로가 보유하고 있는 lock을 요구하면서 무한정 대기하고 있는 상황을 의미한다.
해결책
- 예방
- 각 트랜잭션이 실행되기 전에 필요한 모든 자원을 Lock 한다. (병행성 떨어질 수 있음)
- Lock의 time out 시간을 지정해 시간이 지나면 쿼리를 취소한다. (근본적인 해결은 아님)
- 회피 - time stamp를 통해 어느 트랜잭션이 먼저 들어왔는지 여부에 따라 동작을 달리 함
- wait-die
- 먼저 들어왔으면 기다리고, 나중에 들어왔다면 die하고 나중에 다시 요청
- wound-wait
- 먼저 들어왔으면 선점하고, 나중에 들어왔따면 wait하는 방법
- wait-die
DB 충돌 상황을 개선할 수 있는 방법
비관적 락(Pessimistic Lock) - DB Level
: 테이블의 row에 접근시 Lock을 걸고 다른 Lock이 걸려 있지 않을 경우에만 수정을 가능하게 할 수 있다.
- Transaction_1 에서 table의 Id 2번을 읽음 ( name = Karol )
- Transaction_2 에서 table의 Id 2번을 읽음 ( name = Karol )
- Transaction_2 에서 table의 Id 2번의 name을 Karol2로 변경 요청 ( name = Karol )
- 하지만 Transaction 1에서 이미 shared Lock을 잡고 있기 때문에 Blocking
- Transaction_1 에서 트랜잭션 해제 (commit)
- Blocking 되어있었던 Transaction_2의 update 요청 정상 처리
낙관적 락(Optimistic Lock) - Application Level
: 수정할 때 내가 먼저 이 값을 수정했다고 명시하여 다른 사람이 동일한 조건으로 값을 수정할 수 없게 하는 것
- A가 table의 Id 2번을 읽음 ( name = Karol, version = 1 )
- B가 table의 Id 2번을 읽음 ( name = Karol, version = 1 )
- B가 table의 Id 2번, version 1인 row의 값 갱신 ( name = Karol2, version = 2 ) 성공
- A가 table의 Id 2번, version 1인 row의 값 갱신 ( name = Karol1, version = 2 ) 실패
- Id 2번은 이미 version이 2로 업데이트 되었기 때문에 A는 해당 row를 갱신하지 못함
위 flow를 통해서 같은 row에 대해서 각기 다른 2개의 수정 요청이 있었지만 1개가 업데이트 됨에 따라 version이 변경되었기 때문에 뒤의 수정 요청은 반영되지 않게 된다.
이렇게 낙관적락은 version과 같은 별도의 컬럼을 추가하여 충돌적인 업데이트를 막는다.
version 뿐만 아니라 hashcode 또는 timestamp를 이용하기도 한다.
무슨 차이인가?
- 낙관적 락의 장점은..
- 트랜잭션을 필요로 하지 않는다.
- 성능적으로 비관 락보다 더 좋다.
- 어플리케이션 단에서 충돌을 감지할 수 있다.
- 낙관적 락의 단점은..
- 롤백을 수동으로 처리해줘야한다.
성능적으로 좋겠지만, 충돌이 많이 예상되거나 충돌이 발생했을 때 비용이 많이 들 것이라고 판단되면 사용하지 않는 것이 좋다.
Reference
https://jaehoney.tistory.com/162
Database - 교착상태 문제를 해결하는 방법!
DB(데이터베이스)에서의 교착상태 운영체제에서 교착상태(Dead Lock)는 각각의 프로세스가 서로의 자원을 점유하기 위해 대기하면서 문제가 발생한다 DB(데이터베이스)에서 교착상태는 여러 개의
jaehoney.tistory.com
'Computer Science > Database' 카테고리의 다른 글
SQL Injection (0) | 2024.04.23 |
---|---|
CAP 이론 (0) | 2024.04.23 |
클러스트링과 Replication (0) | 2024.04.23 |
파티셔닝과 샤딩 (0) | 2024.04.23 |
DB Index (0) | 2024.04.23 |