On Apr 8, 2009, at 2:13 AM, Dave Brown wrote: > But why is this deadlocking at all? I thought there shouldn't be a > problem doing this, especially since thread B is using a transaction. > Shouldn't either A or B prevent the other one from accessing the > database until they are done?
It is a problem because people have asked for more concurrency. So we provide more concurrency. But concurrency comes at a price: namely the danger of a deadlock. You can do "BEGIN EXCLUSIVE" to absolutely prevent the deadlock. This will also prevent any possibility of concurrency. Or, since you are dealing with threads within a process, enable shared- cache mode and then on the reader thread set "PRAGMA read_uncommitted=ON". This will allow the reader to see uncommitted changes from the writer, and hence never block for anything. You will get great concurrency and no possibility of deadlock. The downside there is that you lose isolation - the "I" in "ACID". Choose your poison. D. Richard Hipp d...@hwaci.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
