Commit c225a6cfce24bd7b14add5c91822cfe7a78c1bcb breaks a pool with a memory file about sqlite HOT 6 CLOSED

https://www.sqlite.org/sharedcache.html

Enabling shared-cache for an in-memory database allows two or more database connections in the same process to have access to the same in-memory database.

Without shared-cache, each connection has its own memory database. It should probably be the default for :memory: databases.

from sqlite.

Yeah I think this new value is the right default. I hit a couple of tricky limits of the shared cache that are not intuitive (the granularity of the write locks appears to be coarser in the shared-cache, which can be awkward depending on your table design).

It would be nice to fix those limits in sqlite and always use shared cache mode.

from sqlite.

I definitely also find the new default more appropriate in general, one of my applications was deadlocking just by trying to make a write for each row in a select, because write locks exclude all reads with the shared cache.

However when opening a memory database the semantics of non-shared cache make little sense, so I think it should be on by default when the target is :memory:

from sqlite.

Yes that makes sense.

from sqlite.

This should probably still be open. I just realized "not fix #57" still set off GitHub's issue closer.

from sqlite.

Should this still be open? It seems that the user can solve their problem by enabling shared cache via the URI.

from sqlite.