Transaction과 Lock 상태의 이해가 반드시 필요하다.

(보기 불편해서 쬐끔 수정...)

Lock type

unlocked, shared, reserved, pending, exclusive (unlocked 를 제외하고 모두 제각각 Lock 있음)

unlocked : database에 연결, begin transaction으로 Tr 시작 상태

shared : DB에서 read 하려고 하는 모든 세션이 획득해야 함 - 다중 세션에서 read 가능하고, shared 락은 활성화 되어 있지만 어떤 세션도 wrtie는 안됨

reserved : wrtie 하고자 하는 세션은 reserved 획득해야 함. 다른 read 세션은 방해하지 않으며, 새로 접근 하는 read 세션도 허용한다. 적용하는 변경 내역은 메모리에 캐시 된다.

exclusive : reserved 락을 획득한 세션에서 변경 내역(or Tr)을 commit 하려면 획득해야 함

pending : reserved 가 exclusive 를 획득하기 위해서는 pending 을 먼저 획득해야 함 - pending lock을 획득하면 새로운 shared lock 제한하고, shard lock들이 모두 끝나길 기다린다. 기다림이 끝나면 pending -> exclusive로 전환되면서 모든 사항 반영한다.

요약 : READ : unlocked -> shared

         WRITE : unlocked -> shared -> reserved -> pending -> exclusive

Transaction Type (deferred, immediate, exclusive)

begin [ deferred | immediate | exclusive ] transaction;

deferred : Tr type을 명시하지 않았을 경우 default 값이며, 어떤 락도 생성하지 않고, unlocked로 시작함.

DB의 첫번째 읽기 연산에서 shared lock 획득 시도.

DB의 첫번째 쓰기 연산에서 reserved lock 획득 시도.

immediate : begin 명령이 실행 되자마자 reserved 락 획득 시도.

성공 시, 어떤 다른 세션도 DB에 쓸 수 없게 begin immediate 명령이 보장함.

기존에 shared lock 획득 세션은 읽기 계속 할 수 있으나, 새로운 세션에서는 읽지 못하게 reserved lock이 막음.

다른 어떠한 세션도 begin immediate 나 begin exclusive 명령을 성공적으로 실행할 수 없음.

      ERROR CODE : SQLITE_BUSY

이렇게 시작된 Tr은 데이터 변경은 가능하나 commit은 불가. commit 수행 시

      ERROR CODE : SQLITE_BUSY

shared lock을 획득한 다른 세션에서 DB 읽고 있기 때문. 해당 세션들 shared lock 모두 해제 후 Tr commit 가능하다.

exclusive : Tr은 해당 DB의 exclusive lock 획득.

immediate 와 유사하나, 이 lock을 획득하면 어떤 다른 세션도 그 DB를 사용할 수 없어서 읽기/쓰기를 마음대로 할 수 있다.

DB에 쓰기에 있어서 concurrent 를 고려해야 하는 상황 이라면 일단은 transaction type을 deferred 가 아닌 것으로 주어 동기화 이슈를 회피 가능하다.