- reserved state
Get into reserved state in the future ,sqlite You can modify the contents of the database , But write the revised content to pager In the cache of , Size by page cache Appoint . After entering this state ,pager Start initializing log file , User rollback and exception recovery .（ In fact, it is to copy the file content in the log to the database file ） This mechanism enables the database to read while writing . But because there's only one reserved or exclusive lock , So there can only be one write operation
- pending state
from reserved To exclusive To experience a pending state, That is to get pending lock . pending It's a gateway lock.
- There will be no business from unlock State to shared state , No new read and write operations are guaranteed
- Already owned shared The transaction of lock can run normally . Write transactions waiting for them to complete , Release the lock .
When all the other database links have released the lock , There is only one write transaction in the whole database . Get into Exclusive state .
- If SYNCHRONOUS PRAGMA It's the default setting , Will call once sync operation .
- If SYNCHRONOUS PRAGMA yes FULL, Will call twice sync operation
- If SYNCHRONOUS PRAGMA yes NONE, Not invoke sync operation
- pager Check that the log file has been written to disk , call fsync() system call （ If the system call hangs ,SQlite There is no way ）
- pager Write the modified content to the database file
- Clean up log files , Release the lock
The principle of lock implementation
SQLite The implementation of the lock is based on the standard file lock .SQlite There are three locks on the database file ,1 individual reserved byte, One pending byte And one. shared region.
obtain pending byte Read lock . After success , stay shared region Get one at random byte Read lock , And release pending byte Read lock .
obtain reserved byte You can write the lock .
First of all get pending byte Write lock of .
Once the successful , So because of pending byte It's locked in , So there won't be unlocked->shared. Next , Will try to get the whole shared region Write lock of . because shared region Some were active The transaction holding the read lock , So the database will wait for these transactions to complete and release the lock .
Use reserved byte To decide if it needs to be restored .
Generally speaking , Log files and reserved lock It's synchronous , That is, they appear and disappear at the same time .
If SQLite A log file was found , I didn't see it reserved lock, So it can be said that crash Or system power down .
When pager The first time you open a database or read to memory from a database file , I'll do an integrity check . If inconsistencies are found （ There are log files, but not reserved lock）, So the database goes into recovery mode . The database log file at this time is called hot journal.
After entering recovery mode , Directly from shared Status entry pending state , As the gray line in the first figure shows . This will ensure that
1. There will be no new database connections
2. shared A database connection that is not in recovery mode （ It doesn't actually happen , Because the first database connection goes into recovery mode , Thus blocking other database connections into shared state ）
To put it simply , One hot journal It's just one. implicit exclusive lock . If the write operation crash 了 , Then, before other database connections succeed in restoring the database , There will be no other operations in the database .crash After the first operation of the database pager Will see hot journal, And database recovery .
About file locks
File locks really are just flags within the operating system kernel, usually. (The details depend on the specific OS layer interface.) Hence, the lock will instantly vanish if the operating system crashes or if there is a power loss. It is usually also the case that the lock will vanish if the process that created the lock exits.