On 04/22/2016 02:59 PM, Dominique Devienne wrote: >> But, if your process has two separate database handles and they both >> attach "file:data.db?mode=memory&cache=shared" then both handles will be >> connected to the same in-memory database. > > This is exactly what we are doing. Now I keep on reading in this list > cache=shared is for constrained devices and one shouldn't use it ever. > > But how else to use an in-memory database from multiple threads and > leverage table-level locking as opposed to DB-level locking? > > We are heavy users of vtables and in-memory DBs, plural, within the same > process. And would like to have some //ism on tables. > I'd even wish for WAL-type MVCC for in-memory databases to avoid locks even > more. Is WAL mode supported for in-memory DBs?
Not supported. You could create a custom VFS that worked with wal mode but stored all files in memory instead of writing them out to the file-system. I don't think anyone has published anything like that yet though. > > What is "wrong" with shared cache that people keep saying don't use it? > Dan, Richard, is shared cache broken somehow? For many applications, using shared-cache mode with on-disk databases decreases concurrency, especially for wal mode databases. And a lot of the time the memory saved doesn't offer any perceptible performance benefits. So I guess the standard advice should really be "Don't turn this on just because it sounds good, wait until you have a reason." - like wanting to access an in-memory database from more than one database handle within a process. It's not broken in any way to my knowledge. Dan.
