> Therefore, SQLite > returns SQLITE_BUSY for the first process, hoping that this will > induce the first process to release its read lock and allow the > second process to proceed. [snip] > In short, you can poke at a SQLITE_BUSY state for a bit, but fairly > soon you should give up and back all the way out. If you don't, a > deadlock is possible. But that would be considered an application > bug, not an SQLite bug.
That's exactly what I meant - that SQLite doesn't dead locks inside its own code but returns SQLITE_BUSY instead and only application's code can cause a dead lock. Pavel On Fri, Oct 16, 2009 at 12:37 AM, Jay A. Kreibich <j...@kreibi.ch> wrote: > On Thu, Oct 15, 2009 at 10:57:11PM -0400, Pavel Ivanov scratched on the wall: >> You're definitely talking about some bug in your application or some >> misunderstanding about how SQLite should work. SQLite by itself never >> causes any deadlocks. > > As I understand it, that's not exactly true. SQLite can and does > deadlock. It also tries to detect when this is happening and > encourage the application to break the deadlock. This depends on the > applications' cooperation, however. > > From <http://www.sqlite.org/c3ref/busy_handler.html> : > > 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 > returns SQLITE_BUSY for the first process, hoping that this will > induce the first process to release its read lock and allow the > second process to proceed. > > This implies that SQLite can figure out what is going on, but will > not automatically rollback a transaction and break the deadlock by > itself. That also implies that if an application goes into an infinite > "try again" loop whenever it gets an SQLITE_BUSY return code, the > deadlock may persist. > > The page <http://www.sqlite.org/lang_transaction.html> is clear that > this is the expected behavior, on behalf of the application: "It is > recommended that applications respond to the errors listed above > [including SQLITE_BUSY] by explicitly issuing a ROLLBACK command." > > In short, you can poke at a SQLITE_BUSY state for a bit, but fairly > soon you should give up and back all the way out. If you don't, a > deadlock is possible. But that would be considered an application > bug, not an SQLite bug. > > -j > > -- > Jay A. Kreibich < J A Y @ K R E I B I.C H > > > "Our opponent is an alien starship packed with atomic bombs. We have > a protractor." "I'll go home and see if I can scrounge up a ruler > and a piece of string." --from Anathem by Neal Stephenson > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
