|
《SQLite学习笔记（二）》要点：
本文介绍了SQLite学习笔记（二），希望对您有用。如果有疑问，可以联系我们。
代码下载 git clone git@github.com:mackyle/sqlite.git
SQLite的锁 journal模式五种锁状态： UNLOCKED： 文件没有持有任何锁,即当前数据库不存在任何读或写的操作.其它的进程可以在该数据库上执行任意的读写操作.此状态为缺省状态. SHARED： 在此状态下,该数据库可以被读取但是不能被写入.在同一时刻可以有任意数量的进程在同一个数据库上持有共享锁,因此读操作是并发的.换句话说,只要有一个或多个共享锁处于活动状态,就不再允许有数据库文件写入的操作存在. RESERVED： 假如某个进程在将来的某一时刻打算在当前的数据库中执行写操作,然而此时只是从数据库中读取数据,那么我们就可以简单的理解为数据库文件此时已经拥有了保存锁.当保存锁处于活动状态时,该数据库只能有一个或多个共享锁存在,即同一数据库的同一时刻只能存在一个保存锁和多个共享锁.在Oracle中此类锁被称之为预写锁,不同的是Oracle中锁的粒度可以细化到表甚至到行,因此该种锁在Oracle中对并发的影响程序不像SQLite中这样大. PENDING： PENDING锁的意思是说,某个进程正打算在该数据库上执行写操作,然而此时该数据库中却存在很多共享锁(读操作),那么该写操作就必须处于等待状态,即等待所有共享锁消失为止,与此同时,新的读操作将不再被允许,以防止写锁饥饿的现象发生.在此等待期间,该数据库文件的锁状态为PENDING,在比及所有共享锁消失以后,PENDING锁状态的数据库文件将在获取排他锁之后进入EXCLUSIVE状态. EXCLUSIVE： 在执行写操作之前,该进程必需先获取该数据库的排他锁.然而一旦拥有了排他锁,任何其它锁类型都不能与之共存.因此,为了最大化并发效率,SQLite将会最小化排他锁被持有的时间总量.
锁状态转换图： 
一个事务可以在UNLOCKED、RESERVED或EXCLUSIVE三种状态下开始.默认情况下在UNLOCKED时开始. 白色框中的UNLOCKED、PENDING、SHARED和 RESERVED可以在一个数据库的同一时刻存在. 从灰色的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 =1Lock:Pending(Read)Lock:Shared(Read)Unlock:Pending获取Shared读锁前,必要先获取Pending共享锁通过这种方式与写事务互斥.
commitUnLock:Shared
写事务begin
不持有锁Update c1=c1+1 where id =1Lock: Pending(Read)Lock:SharedUnlock:PendingLock:Reserved(Write)先获取Shared读锁,然后获取Reserved排它锁,阻止其它写事务
commitLock: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 =1DB文件：Lock:Pending(Read)Lock:SharedUnlock:PendingWAL文件：Lock：WAL_READ_LOCK(Read)除了获取DB文件锁,还必要获取WAL锁,得到最新提交事务的位点.若有事务再作检查点,必要重试多次.
commitUnlock：WAL_READ_LOCKUnlock：Shared
写事务begin
不持有锁Update c1=c1+1 where id =1DB文件：Lock: Pending-ReadLock:Shared(Read)Unlock:PendingWAL文件：Lock：WAL_READ_LOCK(Read)Lock：WAL_WRITE_LOCK(Write)通过EXCLUSIVE-WRITE-LOCK控制写写并发由于不操作DB文件,因此不存在读写冲突,读写可以并发.
commitWAL文件：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_LOCKEXCLUSIVE-CKPT-LOCK保证只有一个写事务做检查点；WAL_READ_LOCK阻止读写事务.
编程之家PHP培训学院每天发布《SQLite学习笔记（二）》等实战技能，PHP、MYSQL、LINUX、APP、JS,CSS全面培养人才。 （编辑：李大同）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
