On 7/15/2011 1:30 PM, Steven E. Harris wrote: > ,---- > | In shared-cache mode, is it possible for two different connections > | (both connected to the shared cache) to mutate two different tables at > | the same time? > `----
No. > My reading of the documentation[1] on shared-cache mode says no, but my > understanding is further confused by the discussion on this list in > 2009. One discussion thread here[2] from November 2009 touches on the > same question, but never comes to a definitive resolution: All parties in that discussion are mostly wrong. > In another discussion, John Crenshaw suggests[4] that two threads on > separate connections to a shared cache can update separate tables > concurrently. I believe he's wrong, too. > Is it the case that my application should instead lock across all of > these connections against the same shared cache, so that no more than > one thread attempts to issue an INSERT statement or commit a > transaction? Either that, or handle errors that come from SQLite. > Like the others in the aforementioned threads, I too am confused by the > promised benefits of table-level lock granularity. Does that really just > help with allowing readers to continue against one table while a writer > is writing to some other table? That's my understanding, yes. Note that the stated purpose of shared-cache mode is not to improve concurrency, but to "significantly reduce the quantity of memory and IO required by the system." -- Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
