> On 1 Jul 2014, at 10:36pm, Igor Tandetnik <i...@tandetnik.org> wrote: > > On 7/1/2014 5:20 PM, Igor Tandetnik wrote: >> On 7/1/2014 4:55 PM, Clemens Ladisch wrote: >>> To prevent deadlocks, transactions that will modify the database should >>> be started with BEGIN IMMEDIATE. (This kind of lock is not available >>> in shared cache mode.) >> >> Are you sure? Nothing in the documentation appears to suggest that. > > Upon rereading, this sounds ambiguous. I meant - are you sure BEGIN IMMEDIATE > doesn't work in shared cache mode?
My guess is that the OP tested the originally quoted sequence On 7/1/2014 4:40 PM, Srikanth Bemineni wrote: > 10:00.234 Thread 1 BEGIN > 10:00.235 Thread 1 select * from <table1> > 10:00.234 Thread 1 select * from <table x> > 10:00.456 Thread 1 delete from <table1> > > 10:00.456 Thread 2 BEGIN > 10:00.456 Thread 2 select * from <table1> > 10:00.906 Thread 2 select * from <table x> > 10:01.156 Thread 2 delete from <table1> using BEGIN IMMEDIATE instead of BEGIN. Of course, in this case the second BEGIN IMMEDIATE does its job and thread 2 can't get started. OP saw the second BEGIN return an error and concluded that it wasn't working. Because it's hard to see why a SELECT should lock a database until you know what you explained in your previous post: within a transaction SELECT must be repeatable. The solution is to use BEGIN IMMEDIATE as you wrote, but also to set a realistic and acceptable value for timeout using the API call <http://www.sqlite.org/c3ref/busy_timeout.html> or the PRAGMA <http://www.sqlite.org/pragma.html#pragma_busy_timeout> Just a reminder to others that a realistic value for timeout is 2 minutes rather than 2 seconds. Long enough that you are sure that your app has crashed rather than is just handling an unusual but reasonable amount of work. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
