代码下载

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阻止读写事务.