[SQLite3][C++] SQLite 의 file lock 매커니즘

ACID 와 SQLite3

SQLite3 는 Database 의 ACID 를 준수하기 위한 하나의 방법으로 File Locking Mechanism 을 사용한다.

 

잠시 ACID 에 복습해 보자면 아래와 같다.

Atomicity 원자성 : 하나의 논리적 실행단위인 트랜잭션이 도중이 중단되지 않고 끝까지 실행되어야 함

Consistency 일관성 : 트랜잭션 실행이 종료된다면 언제나 일관성 있는 상태의 Database 가 되어야 한다.

Isolation 독립성 : 트랜잭션 수행 중에는 다른 어떠한 트랜잭션이 도중에 끼어들거나 트랜잭션의 중간 작업내용을 볼 수 없음을 의미한다.

Durability 지속성 : 한번 트랜잭션이 수행 되었다면 그 결과는 시스템 장애나 전원 종료 등이 발생하더라도 영구히 남아야 함을 뜻한다.

 

SQLite3 의 Lock 종류

SQLIte3 Database file 은 아래 5 가지 상태의 Lock status 가 될 수 있는데, 각 Lock 의 설명을 첨부하였으니 참고하면 될 듯 하다.

- UNLOCKED : 초기 상태로써, 별도의 Lock 이 걸리지 않은 상태이다. Write 또는 Read 가 수행되고 있지 않음을 의미한다.

- SHARED : Read 가 수행될 때 걸리는 Lock 으로써, 여러 프로세스가 동시에 가질 수 있는 Lock 이다. SHARED Lock 이 존재한다면 어떤 누구도 DB 에 Wirte 를 할수가 없다.

- RESERVED : Write 를 준비중일 때 걸리는 Lock 으로써, 단 하나의 프로세스만이 가질 수 있는 Lock 이다. SHARED Lock 은 추가로 생성될 수 있는 상태이다.

- PENDING : 즉시 Write 를 하기 위해 대기중인 상태를 뜻하는 Lock 으로써, 이 상태에 있게 되면 해당 Database 는 더이상의 새로운 lock 은 획득하지 못한다. 모든 SHARED Lock 이 없어질때까지 대기하는 상태이다. 마찬가지로 하나의 프로세스만이 이 상태에 도달할 수 있다.

- EXCLUSIVE : 모든 SHARED Lock 이 해제 되고, 드디어 DB Write 가 가능한 상태이다. 그 어떤 Lock 도 존재할수 없는 상태이다.

 

이와 같은 여러 상태의 Lock 이 있는 것은 아마 Write 를 시도할 때 지속적인 Read 로 인한 Write 의 기아 현상을 막기 위해서 인것으로 추측된다. RESERVED 상태에 돌입한 순간 더이상의 SHARED lock 이 생성되지 못하고 이는 곧 Read 가 불가능한 상태라는 뜻인데 이것으로 Write 기아 현상을 막는듯 하다.

 

위의 Lock status 들은 Atomicity 와 Isolation 을 구현하기 위해 존재하는 듯 하다.

 

Database 의 지속성과 일관성 등은 Journal Mode 라는 매커니즘으로 구현하였는데, 이는 아래 포스팅을 참고 바란다

 

https://makedotworld.tistory.com/62

[SQLite3][C++] Sqlite3 의 journal file 에 대해

 

 

참고한 사이트

https://www.sqlite.org/lockingv3.html

File Locking And Concurrency In SQLite Version 3