On 7 Mar 2012, at 1:41pm, Pavel Ivanov <paiva...@gmail.com> wrote: > First your second process gets a SHARED lock on the database to read > it, then your first process gets RESERVED lock on the database to > indicate that it will change it. Then your second process tries to > promote its SHARED lock to RESERVED one, sees that RESERVED lock has > been already taken and can't proceed (returns SQLITE_BUSY). At this > point first process can't commit its transaction because there's > SHARED lock on it and second process can't proceed with its > transaction because there's RESERVED lock on it. To continue you have > to rollback transaction in the second process and start it over again. > Another option is to start IMMEDIATE transaction in the second process > to avoid this course of action altogether.
You can avoid writing your own busy-loop for anything involving locking by using <http://sqlite.org/c3ref/busy_timeout.html> The default is zero, so SQLite wouldn't have been handling any timeouts for you. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
