1. 락/데드락 개요
위 트랜잭션 이슈발생을 방지하기 위해, 상대방 트랜잭션이 데이터를 사용하는지에 대한 여부를 확인하여 알아야 한다.
이러한 규칙 및 도구가 락/데드락이며, 데이터 수정 중이라는 사실을 알리는 일종의 잠금장치이다.
2. 락/데드락 진행 과정
T1, T2를 각각 진행되는 트랜잭션이라 하고, 해당 트랜잭션의 데이터가 저장되는 공간을 Data Buffer라 하자.
- T1 처리와 Lock
트랜잭션1이 Data를 수정하기 위해 Buffer X를 LOCK처리하고, 해당 Buffer에 data를 읽어온다(Read).
- T2 wait
T1이 작업을 수행하는 동안 T2는 wait 상태가 되어 해당 data buffer 값을 수정할 수 없다.
- T1 처리 후 Unlock
T1이 Buffer에서 읽어온 데이터를 수정하고, 수정한 데이터를 다시 Buffer에 쓴다(Write).
이후 Buffer를 Unlock한다.
- T2 접근가능
Buffer가 Unlock한 상태가 되어, 이제부터는 T2도 접근 가능한 상태가 된다.
T2가 읽는 Buffer의 데이터는 연산된 이후의 (수정된) 데이터이다.
3. 락의 종류
이러한 LOCK의 종류는 여러가지가 있는데, 트랜잭션의 연산 유형에 따라 두가지로 나눌 수 있다.
공유락, Shared Lock(LS)
트랜잭션 읽기 시 사용하는 락이다.
배타락, Exclusive Lock(LX)
트랜잭션 읽기, 쓰기 시 사용하는 락이다.
3-1. 락 과정
기본적으로 락이 걸려있지 않으면 트랜잭션은 데이터에 락을 걸고, 다른 트랜잭션이 접근하는 것을 차단할 수 있다.
이때 락의 종류에 따라 락 과정 및 기대결과가 다르다.
- LS(X)
데이터를 읽기만 할 경우 LS(X)를 요청하며, LS(X)를 요청한 데이터에 대해선 추가적인 LS(X)만 허용하고 LX(X)는 허용하지 않는다.
- LX(X)
데이터를 읽고 쓸 경우 LX(X)를 요청하며, LX(X)를 요청한 데이터에 대해선 LS(X), LX(X) 모두 허용하지 않는다.
3-2. 데드락
교착상태라고도 하며, 두 트랜잭션이 각자의 자원에 접근하지 못하고 락을 풀지도 못하는 상태를 말한다.
위 그림처럼 두개 이상의 트랜잭션이 각자의 자원(Process -> Resource)을 사용하고 있고 LOCK을 걸었다고 하자.
이 상태에서 Process1이 Resource2를, Process2이 Resource1을 사용하기 위해선 각자 자기 자신의 LOCK을 풀어야 진행이 가능한데, 쿼리 길이 및 Roll back 등 특정 상황에 의해 LOCK이 풀리지 않는다면 교착 상태에 빠진다.
이러한 데드락 상태에서는 각 Process가 LOCK을 풀기 전까지는 절대 풀리지 않기 때문에, DMBS에서 트랜잭션 작업 중 하나를 강제로 중지한다.
이때 중지시키는 트랜잭션의 데이터는 원상복구한다.
4. 트랜잭션 유의사항
- 트랜잭션을 지속적으로 Commit한다.
※ 트랜잭션을 더 작게 단위화하여 쿼리길이를 줄이고, 교착상태를 방지하기 위함 - 정해진 순서로 table에 액세스하도록 한다.
- 필요없는 경우에는 읽기잠금(LS) 획득 사용을 피한다.
- 처리의 잠금 범위를 작게한다.
- table의 부수행을 임의의 순서, 혹은 순서 변경 등 없이 갱신한다면 교착상태에 빠질 가능성이 있다.
- Auto commit은 자제하고, table 단위로 lock하여 직렬화처리한다.
※ 특히 처리단위 Auto Commit 시, Application 측에서 잠금 실행간 과부하가 올 수 있다. - 트랜잭션의 길이를 최소화한다.
※ DB 동시성 및 자원유효성을 저하할 수 있고, 트랜잭션의 길이가 늘어난다면 그만큼 타임아웃이나 교착상태에 빠질 수 있다.
※ 시스템 요건에 따라 적당한 커넥션 수가 필요하다.
5. 참고자료
패스트캠퍼스 - 데이터베이스와 SQLD
데드락 - https://gyoogle.dev/blog/computer-science/operating-system/DeadLock.html
