Today I saw a APSW note about shared cache mode at "https://rogerbinns.github.io/apsw/tips.html#shared-cache-mode";, which led me to "https://sqlite.org/src/tktview/ebde3f66fc64e21e61ef2854ed1a36dfff884a2f";.

Reading the sqlite page at "https://sqlite.org/sharedcache.html"; I see that section "2.2. Table Level Locking" is not very clear or straight-forward. One must read between the lines and surmise in order to understand that the sqlite connection timeout (or callback) mechanisms become useless in this mode in a multi-threaded program. It would be useful if there was a statement that the normal mechanism is rendered useless and that the calling thread must implement its own busy-wait if it must succeed.


The problem report was closed as "works as designed" (works as implemented?).

If the normal busy-wait or callback mechanisms are not supported, then it becomes prohibitive to enable this mode on an existing code base.

Given that each sqlite connection duplicates the entire database schema in RAM, this shared cache mode becomes quite useful on limited memory systems. It would be good if it worked `properly'.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to