ACID를 만족 시키기 위해 하나로 묶어 관리되는 작업의 단위
Atomicity: 원자성, 전부 또는 전무 0 or all
Consistency: 일관성, 컬럼 등의(정해진) 요소가 변해서는 안됨
Isolation: 독립성, 다른 트랜잭션은 서로 영향을 미치지 않음
Durability: 지속성, 데이터가 저장되고 나면, 시스템의 문제에도 보존 가능
Shared lock (공유락, 읽기락) : 읽기에서 쓰이는 락으로 같은 읽기 작업인 경우 하나의 데이터에 대해 공유가 가능하다. 누군가 읽기락 중이더라도 같은 읽기락은 영향없이 작업이 가능하다.
Exclusive lock (배타적락, 쓰기락) : 쓰기(수정, 삭제)에서 쓰이는 락으로 락이 진행되는 동안 다른 락(shared lock)의 접근을 차단한다.
읽기 작업 -> 쓰기 작업 -> 읽기 작업 -> 읽기 작업 -> 읽기 작업......
위와 같은 읽기 작업(1)이 진행중이라 쓰기 작업이 대기중일때 지속적으로(악의적으로) 읽기 작업이 반복해서 들어오는 경우
=> 쓰기 작업은 처음에 읽기 작업의 공유락이 끝나기를 기다리던중 다른 읽기 작업이 지속적으로 들어와서 대기가 무한하게 길어지게 된다.
-> 이후 알고 보니 이와 같은 경우를 starvation 이라 한다.
: 특정작업이 우선순위로 인해 끝없이 밀려나서 lock을 받지 못하는 경우
트랜잭션 락을 진행시 일반적으로는 우선순위가 Shared lock이 우선순위이고 Exclusive lock이 차순위지만 일정숫자 이상의 shared Lock이 쌓인경우에는 exclusive lock에게 우선순위를 주는 형태로 구현할 수 있다 -> 결국 shared lock이 아닌 exclusive lock에게 특정 조건시에 우선권을 준다.
두개 이상의 트랜잭션이 각자 하나씩의 자원을 점유한 상태에서 서로의 자원을 참조하려 대기하는 경우 발생 (처음 각자는 다른 자원(데이터)를 수정하기위해 lock을 걸었기에 서로 각자 x-lock이 걸리게 됨 이후 서로 각자의 자원을 참조(s-lock)하기위해 기존의 x-lock이 끝나길 기다림)-> 영원히 기다림
fifo를 적용, 먼저온 순서대로 lock의 우선도를 가진다.
타임아웃을 지정 일정시간이 지나도록 lock을 획득하지 못할시 롤백
자원 할당 전에 데드락 가능성을 예측하여 안전하게 자원을 할당
주기적으로 데드락을 탐지한뒤 하나의 트랜잭션을 롤백