SQLite之SQLITE_BUSY与sqlite3_busy_handler()

什么时候会返回sqlITE_BUSY错误码？官方文档给出的解释是：

The sqlITE_BUSY result code indicates that the database file Could not be written (or in some cases read) because of concurrent activity by some otherdatabase connection,usually a database connection in a separate process.

这里所说的“数据库连接”实际上指的是用于sqlite3_open函数的sqlite3*结构体指针。也就是说，以下两种情况可能会返回sqlITE_BUSY错误码：

1、同一进程内的多个线程将不同的sqlite3*指针用于sqlite3_open()函数（即打开同一个数据库，但它们是不同的连接，因为sqlite3*指针各自不同），并向同一数据库执行写入操作。

2、不同的进程将不同的sqlite3*指针用于sqlite3_open()函数（即打开同一个数据库，但它们是不同的连接，因为sqlite3*指针各自不同），并向同一数据库执行写入操作。

而sqlite提供的sqlite3_busy_handler() API函数则为我们提供了一种处理sqlITE_BUSY错误码的机制。使用方法是在调用sqlite3_open()函数打开一个数据库连接后，调用sqlite3_busy_handler()注册一个数据库超时回调函数。该回调函数的原型必须类似于:

int busy_callback(void* lpVoid,int c)
{
	return nRet;
}

其中第一个参数为调用sqlite3_busy_handler()时传入的第三个参数的副本。

第二个参数为基于相同锁定事件的回调函数的前一次调用次数。例如，当第一次执行某个sql语句时就

超时了，那么sqlite数据库引擎进入busy_callback回调函数时c为0，即第一次超时。如果第二次尝试还是超时，那

么sqlite数据库引擎进入busy_callback回调函数时c为1，依此类推。

而决定sqlite数据库引擎是否再次尝试执行超时的sql语句是由回调函数的返回值来指定的。当nRet为非0时，sqlite

数据库引擎会等待获得锁，并再次尝试执行超时的sql语句，直到执行完成。如果下一次尝试还是失败，并且nRet为

非0值，则sqlite数据库引擎不断重复上述过程，直到最终执行成功为止。但为了避免进入无限循环，我们可以配合

使用参数c，例如当尝试次数到达3次时就返回0值，表示放弃执行当前的sql语句并不再重复尝试：

int busy_callback(void* lpVoid,int c)
{
    if(2==c)
    {
         return 0;
    }
}