Sqlite3并发读写注意事项

最近项目中涉及到sqlite并发读写的问题,参考一些文档并结合自己的实践,对sqlite3并发问题总结了几点:

sqlite3的锁及事务类型

sqlite3总共有三种事务类型:BEGIN [DEFERRED /IMMEDIATE / EXCLUSIVE] TRANSCATION,五种锁,按锁的级别依次是:UNLOCKED /SHARED /RESERVERD /PENDING /EXCLUSIVE。当执行select即读操作时,需要获取到SHARED锁(共享锁),当执行insert/update/delete操作(即内存写操作时),需要进一步获取到RESERVERD锁(保留锁),当进行commit操作(即磁盘写操作时),需要进一步获取到EXCLUSIVE锁(排它锁)。

对于RESERVERD锁,sqlite3保证同一时间只有一个连接可以获取到保留锁,也就是同一时间只有一个连接可以写数据库(内存),但是其它连接仍然可以获取SHARED锁,也就是其它连接仍然可以进行读操作(这里可以认为写操作只是对磁盘数据的一份内存拷贝进行修改,并不影响读操作)。

对于EXCLUSIVE锁,是比保留锁更为严格的一种锁,在需要把修改写入磁盘即commit时需要在保留锁/未决锁的基础上进一步获取到排他锁,顾名思义,排他锁排斥任何其它类型的锁,即使是SHARED锁也不行,所以,在一个连接进行commit时,其它连接是不能做任何操作的(包括读)。

PENDING锁(即未决锁),则是比较特殊的一种锁,它可以允许已获取到SHARED锁的事务继续进行,但不允许其它连接再获取SHARED锁,当已存在的SHARED锁都被释放后(事务执行完成),持有未决锁的事务就可以获得commit的机会了。sqlite3使用这种锁来防止writer starvation(写饿死)。

死锁的情况

死锁的情况:当两个连接使用begin transaction开始事务时,第一个连接执行了一次select操作(已经获取到SHARED锁),第二个连接执行了一次insert操作(已经获取到了RESERVERD锁),此时第一个连接需要进行一次insert/update/delete(需要获取到RESERVERD锁),第二个连接则希望执行commit(需要获取到EXCLUSIVE锁),由于第二个连接已经获取到了RESERVERD锁,根据RESERVERD锁同一时间只有一个连接可以获取的特性,第一个连接获取RESERVERD锁的操作必定失败,而由于第一个连接已经获取到SHARED锁,第二个连接希望进一步获取到EXCLUSIVE锁的操作也必定失败。就导致了事务死锁。

事务类型的使用原则

在用”begin transaction”显式开启一个事务时,默认的事务类型为DEFERRED,锁的状态为UNLOCKED,即不获取任何锁,如果在使用的数据库没有其它的连接,用begin就可以了。如果有多个连接都需要对数据库进行写操作,那就得使用BEGIN IMMEDIATE/EXCLUSIVE开始事务了。

使用事务的好处是:1.一个事务的所有操作相当于一次原子操作,如果其中某一步失败,可以通过回滚来撤销之前所有的操作,只有当所有操作都成功时,才进行commit,保证了操作的原子特性;2.对于多次的数据库操作,如果我们希望提高数据查询或更新的速度,可以在开始操作前显式开启一个事务,在执行完所有操作后,再通过一次commit来提交所有的修改或结束事务。

对SQLITE_BUSY的处理

当有多个连接同时对数据库进行写操作时,根据事务类型的使用原则,我们在每个连接中用BEGIN IMMEDIATE开始事务,即多个连接都尝试取得保留锁的情况,根据保留锁同一时间只有一个连接可以获取到的特性,其它连接都将获取失败,即事务开始失败,这种情况下,sqlite3将返回一个SQLITE_BUSY的错误,如果我们不希望操作就此失败而返回,就必须处理SQLITE_BUSY的情况,sqlite3提供了sqlite3_busy_handler或sqlite3_busy_timeout来处理SQLITE_BUSY,对于sqlite3_busy_handler,我们可以指定一个busy_handler来处理,并可以指定失败重试的次数。而sqlite3_busy_timeout则是由sqlite3自动进行sleep并重试,当sleep的累积时间超过指定的超时时间时,最终返回SQLITE_BUSY。需要注意的是,这两个函数同时只能使用一个,后面的调用会覆盖掉前次调用。从使用上来说,sqlite3_busy_timeout更易用一些,只需要指定一个总的超时时间,然后sqlite自己会决定多久进行重试以及重试的次数,直到达到总的超时时间最终返回SQLITE_BUSY。并且,这两个函数一经调用,对其后的所有数据库操作都有效,非常方便。

参考:

http://www.sqlite.org/lockingv3.html

http://www.cnblogs.com/hustcat/archive/2009/03/01/1400757.html

时间: 2024-10-14 21:26:46

Sqlite3并发读写注意事项的相关文章

php中并发读写文件冲突的解决方案(文件锁应用示例)

PHP(外文名: Hypertext Preprocessor,中文名:“超文本预处理器”)是一种通用开源脚本语言.语法吸收了C语言.Java和Perl的特点,入门门槛较低,易于学习,使用广泛,主要适用于Web开发领域.PHP的文件后缀名为php. 本文为大家讲解的是php中并发读写文件冲突的解决方案(文件锁应用示例),感兴趣的同学参考下. 在这里提供4种高并发读写文件的方案,各有优点,可以根据自己的情况解决php并发读写文件冲突的问题. 对于日IP不高或者说并发数不是很大的应用,一般不用考虑这

php中并发读写文件冲突的解决方案

在这里提供4种高并发读写文件的方案,各有优点,可以根据自己的情况解决php并发读写文件冲突的问题. 对于日IP不高或者说并发数不是很大的应用,一般不用考虑这些!用一般的文件操作方法完全没有问题.但如果并发高,在我们对文件进行读写操作时,很有可能多个进程对进一文件进行操作,如果这时不对文件的访问进行相应的独占,就容易造成数据丢失.例如:一个在线聊天室(这里假定把聊天内容写入文件),在同一时刻,用户A和用户B都要操作数据保存文件,首先是A打开了文件,然后更新里面的数据,但这里B也正好也打开了同一个文

共享变量的并发读写

在高性能并发服务器中,对于共享对象的读写是最常见的操作之一,比如全局配置类对象的并发读取和更新,以及更复杂的如copy on write btree.堆栈等的并发读写,最基本的操作都可以简化理解为通过全局共享的指针,并发读取和更新指针所指向对象的操作.最简单的模型如下所示,一个包含了多个字段的结构体: struct GConf { int64_t a; int64_t b; int64_t c; }; 可以通过一个全局指针struct gConf *g_conf进行访问.有多个线程会同时读取或更

Erlang提高ETS并发读写性能

ETS是Erlang内置的内存数据库,可用于多进程共享数据,具有并发读写的性能,文章就这点展开探讨,重点说说ets并发读写两个参数的优缺点及适用场合. 比如新建一个person的ets表: ets:new(person, [set, public, named_table, {write_concurrency, true}, {read_concurrency, true} ]). 说说ets并发读写的两个参数:write_concurrency / read_concurrency writ

linux下高并发网络应用注意事项

本文转自:http://www.blogjava.net/bacoo/archive/2012/06/11/380500.html linux下高并发网络应用注意事项 vi /etc/sysctl.conf,加入以下内容:net.ipv4.tcp_tw_reuse=1 #表示开启重用.允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭net.ipv4.tcp_tw_recycle=1 #表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表

golang中map并发读写问题及解决方法

一.map并发读写问题 如果map由多协程同时读和写就会出现 fatal error:concurrent map read and map write的错误 如下代码很容易就出现map并发读写问题 func main(){ c := make(map[string]int)       go func() {//开一个协程写map            for j := 0; j < 1000000; j++ {              c[fmt.Sprintf("%d",

golang map并发读写异常导致服务崩溃

昨天突然接到报警说服务端口丢失,也就是服务崩溃了. 1, 先看错误日志,发现是调用json.Marshal时出错了,错误原因是:concurrent map iteration and map write,即并发读写map. fatal error: concurrent map iteration and map write goroutine 543965 [running]: runtime.throw(0xb74baf, 0x26) /usr/local/go1.10.1/src/run

sqlite3 解决并发读写冲突的问题

1 #include "stdafx.h" 2 #include "sqlite3.h" 3 #include <iostream> 4 #include <process.h> 5 6 //sqllite 相关变量 7 sqlite3 *sql_db; 8 char *sql_ErrMsg; 9 int sql_rc; 10 sqlite3_stmt *sql_statement; 11 12 //写入重试客克服锁库的问题 13 void

java SE程序关于高并发的注意事项

最近做一个java SE程序.使用线程池进行高并发任务的处理.其中任务处理过程中会有查询数据库操作,导致任务处理非常迟缓.于是在网上查找资料.最终解决现在把有关的注意事项进行总结.一.关于线程池的注意事项.对于多个任务,线程池最好不要公用.应该把线程池分开关于线程池的代码 </pre><pre code_snippet_id="547077" snippet_file_name="blog_20141209_1_7940215" name=&quo