Igor Tandetnik wrote: > On 1/26/2011 6:39 PM, Eric Smith wrote: > > busy handler not called on lock escalation > > This behavior is by design. See > > http://sqlite.org/c3ref/busy_handler.html > > the part that talks about a deadlock.
Understood & agreed. This is a bug in the Tcl API documentation, which can lead the unwary Tcl programmer to believing the busy callback will be called in all cases of contention. I recommend adding some text to the section 'The "busy" method'. This example was largely lifted from the C API doc: == The presence of a busy handler does not guarantee that it will be invoked when there is lock contention. If SQLite determines that invoking the busy handler could result in a deadlock, it will go ahead and throw an error instead of invoking the busy handler. Consider a scenario where one process is holding a read lock that it is trying to promote to a reserved lock and a second process is holding a reserved lock that it is trying to promote to an exclusive lock. The first process cannot proceed because it is blocked by the second and the second process cannot proceed because it is blocked by the first. If both processes invoke the busy handlers, neither will make any progress. Therefore, SQLite throws an error for the first process, hoping that this will induce the first process to release its read lock and allow the second process to proceed. See http://www.sqlite.org/lockingv3.html for more details. == Eric -- Eric A. Smith Slurm, n.: The slime that accumulates on the underside of a soap bar when it sits in the dish too long. -- Rich Hall, "Sniglets" _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
