代码下载

git clone git@github.com:mackyle/sqlite.git

SQLite的锁

journal模式

五种锁状态：

1. UNLOCKED：

2. 文件没有持有任何锁，即当前数据库不存在任何读或写的操作。其它的进程可以在该数据库上执行任意的读写操作。此状态为缺省状态。

3. SHARED：

4. 在此状态下，该数据库可以被读取但是不能被写入。在同一时刻可以有任意数量的进程在同一个数据库上持有共享锁，因此读操作是并发的。换句话说，只要有一个或多个共享锁处于活动状态，就不再允许有数据库文件写入的操作存在。

5. RESERVED：

6. 假如某个进程在将来的某一时刻打算在当前的数据库中执行写操作，然而此时只是从数据库中读取数据，那么我们就可以简单的理解为数据库文件此时已经拥有了保留锁。当保留锁处于活动状态时，该数据库只能有一个或多个共享锁存在，即同一数据库的同一时刻只能存在一个保留锁和多个共享锁。在Oracle中此类锁被称之为预写锁，不同的是Oracle中锁的粒度可以细化到表甚至到行，因此该种锁在Oracle中对并发的影响程序不像SQLite中这样大。

7. PENDING：

8. PENDING锁的意思是说，某个进程正打算在该数据库上执行写操作，然而此时该数据库中却存在很多共享锁(读操作)，那么该写操作就必须处于等待状态，即等待所有共享锁消失为止，与此同时，新的读操作将不再被允许，以防止写锁饥饿的现象发生。在此等待期间，该数据库文件的锁状态为PENDING，在等到所有共享锁消失以后，PENDING锁状态的数据库文件将在获取排他锁之后进入EXCLUSIVE状态。

9. EXCLUSIVE：

10. 在执行写操作之前，该进程必须先获取该数据库的排他锁。然而一旦拥有了排他锁，任何其它锁类型都不能与之共存。因此，为了最大化并发效率，SQLite将会最小化排他锁被持有的时间总量。

锁状态转换图：

1. 一个事务可以在UNLOCKED、RESERVED或EXCLUSIVE三种状态下开始。默认情况下在UNLOCKED时开始。

2. 白色框中的UNLOCKED、PENDING、SHARED和 RESERVED可以在一个数据库的同一时刻存在。

3. 从灰色的PENDING开始，事情就变得严格起来，意味着事务想得到排它锁(EXCLUSIVE)(注意与白色框中的区别)。

读事务

db = open('foods.db')

db.exec('BEGIN')

db.exec('SELECT * FROM episodes')

db.exec('SELECT * FROM episodes')

db.exec('COMMIT')

db.close()

由于显式地使用了BEGIN和COMMIT，两个SELECT命令在一个事务下执行。第一个exec()执行时，连接处于SHARED，然后第二个exec()执行。当事务提交时，连接又从SHARED回到UNLOCKED状态.

相应的状态真正的变化过程为:UNLOCKED→PENDING(1)→PENDING、SHARED(2)→SHARED（6）→UNLOCKED

如果没有BEGIN和COMMIT两行，两个SELECT都运行于自动提交状态

相应的状态真正的变化过程为:UNLOCKED→PENDING→SHARED→UNLOCKED→PENDING→SHARED→UNLOCKED

写事务

类型	操作	锁信息	说明
读事务	begin		不持有锁
select c1 from user where id =1	Lock:Pending(Read)Lock:Shared(Read)Unlock:Pending	获取Shared读锁前，需要先获取Pending共享锁通过这种方式与写事务互斥。
commit	UnLock:Shared
写事务	begin		不持有锁
Update c1=c1+1 where id =1	Lock: Pending(Read)Lock:SharedUnlock:PendingLock:Reserved(Write)	先获取Shared读锁，然后获取Reserved排它锁，阻止其它写事务
commit	Lock:Pending(Write)Lock:Exclusive(Write)Unlock: PendingUnlock:Exclusive(Write)	获取Pending的排它锁，阻止新的读事务，最后上排它锁，阻止所有读事务，读写不能并发Pending锁方式好处是，减少写饿死的几率。

WAL机制

WAL日志文件锁

WAL日志锁实质是锁wal-index文件的区域，根据不同的锁类型，将wal-index文件的不同区域划定义成不同的锁，主要有读锁，写锁，检查点锁。WAL模式下，最新的数据位于日志文件中，无论是读事务还是写事务都需要持有WAL_READ_LOCK的读锁，因为它们都需要获取最新的事务点。因此，做检查点时，可以通过对WAL_READ_LOCK位置(124-127)上锁，来确定检查点需要等待还是停止推进。同时我们也可以看到，对于DB文件，读写事务都只需要对DB文件上读锁，对于WAL日志文件，WAL_READ_LOCK和WAL_WRITE_LOCK位于不同的位置，读写相互不影响，所以读写不互斥。

类型	操作	锁信息	说明
读事务	begin		不持有锁
select c1 from user where id =1	DB文件：Lock:Pending(Read)Lock:SharedUnlock:PendingWAL文件：Lock：WAL_READ_LOCK(Read)	除了获取DB文件锁，还需要获取WAL锁，得到最新提交事务的位点。若有事务再作检查点，需要重试多次。
commit	Unlock：WAL_READ_LOCKUnlock：Shared
写事务	begin		不持有锁
Update c1=c1+1 where id =1	DB文件：Lock: Pending-ReadLock:Shared(Read)Unlock:PendingWAL文件：Lock：WAL_READ_LOCK(Read)Lock：WAL_WRITE_LOCK(Write)	通过EXCLUSIVE-WRITE-LOCK控制写写并发由于不操作DB文件，因此不存在读写冲突，读写可以并发。
commit	WAL文件：Lock：SHARED-READ-LOCKUnlock：WAL_READ_LOCK(Read)Unlock： WAL_WRITE_LOCK(Write)DB文件：Unlock：Shared	获取SHARED-READ-LOCK目的是为了获取最新提交日志的位点
checkpoint		WAL文件：Lock：WAL_CKPT_LOCK(write)Lock：WAL_READ_LOCK(write)UnLock：WAL_READ_LOCKUnLock：WAL_CKPT_LOCK	EXCLUSIVE-CKPT-LOCK保证只有一个写事务做检查点；WAL_READ_LOCK阻止读写事务。