On 28 July 2018 at 05:41, Rune Torgersen <ru...@innovsys.com> wrote: > > Rowan Worth Thu, 26 Jul 2018 22:02:50 -0700 > > > > On 26 July 2018 at 05:56, Rune Torgersen <ru...@innovsys.com> wrote: > > > > > The databases have been opened with two connections (one for reads, one > > > for writes), and use the following options: > > > sqlite3_busy_timeout(mDbConn, 500); > > > sqlite3_exec(mDbConn, "PRAGMA locking_mode = EXCLUSIVE;", 0, 0, 0); > > > > > > > Surely this effectively reduces your number of connections to one? > > No, both connections are from within the same application, and have seemed > to work just fine for about 10 years now... >
If the write connection is held open I honestly can't see how that's possible, unless it is never actually used to write. I tried a quick test with two connections on different threads configured like this, and as soon as the writer obtains an exclusive lock for the first time it holds onto it forever (as described in the PRAGMA docs). From that point on the reader cannot even obtain a SHARED lock to read the database, and spends the rest of its life in the busy handler. Note that while the pragma talks about excluding other "processes" from accessing the DB, "process" and "thread" are interchangeable as far as sqlite is concerned. That is documented here: https://www.sqlite.org/lockingv3.html Last paragraph of section 2.0: > > The pager module effectively controls access for separate threads, or > separate processes, or both. Throughout this document whenever the word > "process" is written you may substitute the word "thread" without changing > the truth of the statement. > Ah, unless you're in shared cache mode (which PRAGMA read_uncommitted would suggest), which I don't really know anything about... -Rowan _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
