第1个参数是通过sqlite3_busy_handler函数传递过来的用户数据指针。第2个参数是一个计数器，每次busyhandler被调用时该计数器的计数递增。如果该回调函数返回0，则sqlite将放弃获取锁的操作，并返回sqlITE_BUSY。如果该函数返回一个非0值，则sqlite将继续尝试获取锁的操作。

需要注意的是：一个数据库连接仅仅可以拥有一个busyhandler，不能同时设置自定义的busyhandler并配置内置的基于定时器的busyhandler。每次设置其中一种busyhandler都将删除另一个busyhandler。

死锁（Deadlocks）

为一个数据库连接设置busyhandler不能够解决所有问题。有的时候在多个数据库连接之间会出现死锁现象。比如两个数据库连接各自持有一些锁，但是它们现在都在等待对方持有的锁被释放，这样就会造成死锁现象。唯一的解决办法，就是其中一个数据库连接放弃获取锁的操作，并释放自己所持有的锁。

如果sqlite检测到了一个潜在的死锁情况，它将跳过busyhandler，并将有一个数据库连接立刻返回sqlITE_BUSY。这样做是为了鼓励应用程序释放他们自己的锁，以打破死锁现象。

避免sqlITE_BUSY（AvoidingsqlITE_BUSY）

如果我们在开发某个项目时需要充分考虑数据库的并发性能，最简单的方法是使用sqlite3_busy_timeout设置内置的busyhandler，并且超时时间在250-2000毫秒范围内进行调整，这样可以减少sqlITE_BUSY的产生。

如果想完全避免sqlITE_BUSY，唯一的办法就是确保对于同一个数据库某一个时刻仅仅存在一个数据库连接。这需要设置PRAGMAlocking-mode为EXCLUSIVE（独占的）。

另外，应用程序可以使用独占模式（EXCLUSIVE）的事务，这样对于sqlITE_BUSY返回值的处理就更容易些。可以通过BEGINEXCLUSIVETRANSACTION命令开启一个独占式的事务，如果成功则在事务的执行过程中不会返回sqlITE_BUSY。不过BEGIN命令本身可能会执行失败并返回sqlITE_BUSY，但这种情况处理起来很容易，应用程序可以通过sqlite3_reset函数重置BEGIN语句，然后重试。BEGINEXCLUSIVE的缺点是只有目前没有其他的数据库连接（包括只读事务）正在访问该数据库，它才会执行成功。而且一旦独占式的事务开始执行，它同样会锁住数据库，使其他的数据库连接（包括只读事务）无法访问该数据库。

为了允许更多的并发访问，还有一种类型的事务——IMMEDIATETRANSACTION（即时事务）。可以通过BEGINIMMEDIATETRANSACTION命令启动一个即时事务，如果成功则在事务执行的过程中通常只有执行到COMMIT语句时才会返回sqlITE_BUSY。不管是事务中的哪些命令（包括COMMIT），一旦遇到了sqlITE_BUSY，应用程序可以简单的重置语句然后等待并重试。BEGINIMMEDIATE语句本身也有可能会遭遇sqlITE_BUSY，这时应用程序也是可以简单的重置BEGIN语句然后重试。与EXCLUSIVETRANSACTION不同的是，如果存在其它的数据库连接正在读取（非写）数据库，这时候IMMEDIATE事务是可以启动的。一旦IMMEDIATE事务成功启动，则不允许其它数据库连接进行写入操作，但只读的数据库连接仍然可以访问数据库，除非IMMEDIATE事务正在强制修改数据库文件（通常是事务正在执行COMMIT操作）。使用IMMEDIATE事务不会发生死锁现象，所有的sqlITE_BUSY可以通过重试操作进行处理。

避免死锁（Avoidingdeadlocks）

避免死锁的原则比较简单，不过遵循这些原则会使应用程序变得复杂一些。

首先，sqlite3_prepare_xxx、sqlite3_backup_step、sqlite3_blob_open函数调用不会产生死锁现象。任何时候如果这些函数返回sqlITE_BUSY，简单的等待一下然后重试即可。

如果在一个（deferred）事务中，sqlite3_step、sqlite3_reset、sqlite3_finalize函数返回sqlITE_BUSY，则应用程序必须回退然后重试。如果这些语句不在一个显示的（explicit）事务中，prepared语句可以简单的重置然后重新执行。如果这些语句在一个显示的（explicit）事务中，那么整个事务就必须回退，然后从头开始执行。致使回退的整个原因就是其他一些数据库连接需要修改数据库。另外需要注意的是，如果应用程序完成了一些读取操作并准备进行写操作，那么在新的事务中最好重新读取这些信息以确定这些数据仍然有效。

不管你做什么，不要忽视sqlITE_BUSY。它可能很少发生，但如果处理不当它就可能成为大麻烦的源头。

当“繁忙”转换为“被阻塞”（WhenBUSYbecomesBLOCKED）

当一个连接需要修改数据库中的数据，数据库就要被加锁使其对于其他连接处于只读状态。事实上，事务中对于数据库的某个修改并没有马上写入数据库文件，而是保存在数据库的页缓存中。因为如果将这个修改直接写入数据库，那么这个修改对于其他的读连接就可见了，这就打破了事务的隔离性原则。

当所有需要的修改操作全部做完，事务开始准备提交。这时数据库文件会被进一步锁定，不允许新的只读事务启动。允许已经存在的读操作（reader）完成，并释放他们持有的数据库锁。当所有的读操作完成，写操作（writer）就要独占式的访问数据库，最终将页缓存中的修改刷新到数据库中。

这一过程允许写事务正在执行的同时，只读事务依然可以继续运行。当写事务确实在提交数据时，读事务被锁定。然而，一个关键的假设是在这个过程中，所有修改被放入页缓存中，直到事务提交的时候才被写入数据库。如果缓存（cache）中装满了（包含处于悬挂状态的修改的）数据页，那么写事务没有其它选择，只能给数据库加一个独占锁，并且在提交（commit）阶段之前刷新缓存。该事务仍然可以在任何时候回滚，但是写入操作必须获得独占锁的即时访问，以刷新缓存。

如果这个锁不是立即可用，写入操作就会被强制终止整个事务。写入事务将回退，然后返回扩展码sqlITE_IOERR_BLOCKED。因为事务是自动回退的，所以应用程序没有更多选择，只能重新启动事务。

为了避免这种情况，最好是用显示的BEGINEXCLUSIVE语句启动一个可以修改多行数据的大事务。BEGINEXCLUSIVE也许会失败，并返回sqlITE_BUSY，但是应用程序可以简单的重新尝试直到成功。一旦一个独占式的事务成功启动，它就可以完整的访问数据库，消除sqlITE_IOERR_BLOCKED的出现，甚至事务在提交之前就造成了缓冲区溢出（增加数据库缓存会有所帮助）。