Thanks for you reply Keith, On Fri, Jul 10, 2015 at 1:30 AM, Keith Medcalf <kmedcalf at dessus.com> wrote:
> > Turn off shared-cache mode. > > Shared-cache is designed for use on itty-bitty-tiny computers with only a > few KB of RAM and very paltry CPU resources. On equipment for which shared > cache was designed, you are unable to run "intense database actions" on > multiple threads, and are therefore unlikely to trip over the additional > limitations it imposes. > ?My server is a hand-written application server, for all intents and purposes you may consider it as a web server (e,g, Apache) serving and managing database data for? many concurrent clients from the same database file. I implemented shared-cache mode not? as much for memory conservation but to facilitate table-level locking instead of database-wide locking. I finally managed to solve the problem by incorporating a manual retry loop with exponential back-off logic in the equivalents of blocking_step() and blocking_prepare_v2() (see https://www.sqlite.org/unlock_notify.html). I can disable shared-cache just by altering a server config file, but this would mean retesting the whole application, especially in high-contention scenarios, because the database locking model will have significantly changed, so I would prefer to keep shared-cache and table-level locking if I can. If anyone can think of another reason why ? shouldn't please speak up. -- Constantine.
