On 7 Mar 2012, at 1:55pm, Pavel Ivanov <paiva...@gmail.com> wrote: > On Wed, Mar 7, 2012 at 8:49 AM, Simon Slavin <slav...@bigfraud.org> wrote: >> 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. > > Note: this won't help in this case because transaction have to be > rolled back and it can be made by user of SQLite only.
Yeah, I should have explained that the call I wrote about must be used in combination with your recommendation for using IMMEDIATE, not instead of it. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
