SQLite Forum

Are the changes done after a transaction is performed always available to all connections to a database?
Login
> shared cache ... ended up serializing all queries from different connections

During your experiments, did you use "Read-Uncommitted Isolation Mode"? Without that, even read queries are serialized.

> Do you think the private cache could be related to the original behaviour I experienced?

I see that as likely, but have not read enough code or docs to see how SQLite determines that a page cache has become stale.  But I find it hard to imagine that it would go to the persistent store to determine that, as that would reduce the performance of the cache significantly. Further, I do not see your post \#1 as describing a violation of the ACID promise. (No real software could guarantee that all threads in all processes see the same DB at any instant.) Hence, I see a likelihood that the shared cache, (sharable across threads since v3.5.0), will cure the cache staleness issue you are seeing the effects of. And it appears that the read serialization you disliked can be alleviated as described in section 2.2.1 .

You would likely get relief from your stale cache issue by calling [sqlite3_db_cacheflush()](https://sqlite.org/c3ref/db_cacheflush.html) after doing writes. It's worth an experiment to see how that performs relative to using "Read-Uncommitted Isolation Mode" and a single (shared) cache.

When experimenting, you might increase the cache size when there is only one rather than many that are not shared.