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
