SQLite学习笔记（13）-事务（2）

2.3.5 锁和崩溃恢复

SQLite的锁是基于标准文件锁实现的。SQLite在数据库文件上持有三种不同的文件锁：a reserved byte, a pending byte, and a shared region（图2.5）。

图2.5 锁的机制

它们都是从pending byte开始。如图2.4所示，为了从UNLOCKED移动到SHARED，一个连接在pendingbyte会首先尝试获取读锁。如果成功了，它就会在shared region的随机字节获得读锁并会在pending byte释放它。为了从SHARED移动到RESERVED，一个连接会尝试在reserved byte获取写锁。为了从RESERVED到EXCLUSIVE，一个连接会试图在pending byte获取写锁。如果成功，就会引起损耗进程，因为它不允许其他连接在pending byte获取读锁进入SHARED。最后，为了获得EXCLUSIVE锁，这个连接会试图在整个shared region获得写锁。这一步就保证了只有其他所有的SHARED锁被释放之后才能获得EXCLUSIVE锁，因为shared region持有其他所有活跃连接的读锁。

SQLite的崩溃恢复机制就是利用reservedbyte来确定一个数据库是否需要恢复。因为日志文件和RESERVED锁是同步进行，如果pager只看到前一个而没看到后边的那个，那就出问题了。每当pager想要打开数据库或者从数据库取页时，它都会做一个简单的一致性检测。如果它只看到日志文件而没看到RESERVED锁，那就是创建日志文件的进程崩溃了或者系统出了问题。这样，这种日志被称为热日志，而数据库就可能处在不一致状态。为了恢复正常，日志需要“回做”来使数据库恢复到中断事务之前的状态。

为启动回做操作，pager会将数据库放在恢复模式下。它会像图2.4那样直接从SHARED跳到PENDING。只有这种情况下才有这种转换。它跳过reserved锁有两方面的原因：

（1）   保证没有新连接进入数据库

（2）   保证其他在SHARED的活跃连接都不能进入恢复模式。除了恢复连接外其他的都临时挂起。

实际上，一个热日志就是一个隐式的EXCLUSIVE锁。如果一个writer崩溃了，在有连接恢复它之前，数据库中的其他活动都无法进行。