That doesn't sound healthy at all. If your application dies, what happens
to the database? What if something rogue starts hitting it and just chews
up your memory?
IMO, Mem databases should be short lived and treated simply as an
intentional cache. I get they're fast, but, long term life for a
It would also be very helpful if more control about in-memory-databases was
available. As far as I have understood, an in-memory database is deleted when
the last connection closes. This requires me to always hold a connection to an
in-memory database even if don't need it right now.
Maybe one
I’m very interested in the answer to this as I was planning on do the exact
same thing. Not sure my app would even be able to function without WAL mode.
Brian Macy
On Jan 14, 2019, 8:28 AM -0500, Dominique Devienne , wrote:
> On Mon, Jan 14, 2019 at 2:23 PM Wout Mertens wrote:
>
> > AFAIK,
On Mon, Jan 14, 2019 at 2:23 PM Wout Mertens wrote:
> AFAIK, your best bet is to put a file db on a ramdisk (tmpfs).
That's not a very portable solution, and a work-around at best.
I don't see anything technical that would prevent WAL to work for
":memory:".
"Shared-memory" "in-process" is
AFAIK, your best bet is to put a file db on a ramdisk (tmpfs). The
":memory:" DB is per connection only.
Wout.
On Mon, Jan 14, 2019 at 11:37 AM Dominique Devienne
wrote:
> According to [1] WAL mode does not apply to in-memory databases.
> But that's an old post, and not quite authoritative
According to [1] WAL mode does not apply to in-memory databases.
But that's an old post, and not quite authoritative when not from the
official SQLite docs.
I'd like to benefit from the MVCC of WAL mode, but for an in-memory
database,
with different threads, each with its own connection,
6 matches
Mail list logo
