SQLite学习笔记(13)-事务(2)
2015-08-27 11:58
253 查看
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崩溃了,在有连接恢复它之前,数据库中的其他活动都无法进行。
相关文章推荐
- Sqlite学习笔记(五)&&SQLite封锁机制
- Mongodb的安装和简单的使用
- MongoDB知识点
- Mysql开启远程连接方法
- ORACLE RAC 11G 更改 /etc/hosts文件
- SqlParameter的作用与用法
- mysql使用笔记(一)
- redis中的发布订阅(Pub/Sub)
- oracle性能监测语法
- 在Oracle Database 11gR2中已经废弃了 Listener Password
- Hibernate利用@DynamicInsert和@DynamicUpdate生成动态SQL语句
- mysql的数据库的导出与导入
- 数据库设计的三范式
- sqlserver 只有函数和扩展存储过程才能从函数内部执行
- SqlServer数据类型
- 人脸数据库汇总
- 怎么使用js调用后台数据库
- mysql5.6安装 mysql.slave_master_info表不存在的解决方法
- JDBC 连接 mysql数据库
- java 操作mongodb查询条件的常用设置