On Wednesday, 7 January, 2015 22:57, Kevin Benson <kevin.m.ben...@gmail.com> said:
>-- The OP wrote: >On Thu, Dec 25, 2014 at 7:32 AM, Rick Kelly <rpke...@gci.net> wrote: >>*SNIP* >> The database file is located in the same folder as the server. The >server >is >> multi-threaded. I'm using library version 3.8.7.4 >> The database file is opened as follows: >> 1. sqlite3_enable_shared_cache(%SQLITE_OPEN_SHAREDCACHE) > >-- *Presumably* enabling SQLite Shared-Cache Mode likely signals his >intention to HAVE two or more connections, right? If so, with that comes >the Shared-Cache Locking Model at https://www.sqlite.org/sharedcache.html You are right Kevin, and I am guilty of mixing two questions -- this one about implementing your own Client/Server protocol, and one regarding interspersing an UPDATE/COMMIT inside a SELECT on the same connection. In reply to the original post, there is only one connection from the shared cache to the database, and it is this connection where WAL applies. Per table locking and updating with the shared cache is an effect of the shared cache, not WAL. You current configuration seems to be working for you. Unless you have changed the default, all usage of connections from the application to shared cache and shared cache to database are serialized automatically to ensure that concurrency issues do not arise. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
