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. Pavel _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
