Quantcast

Controlling the lifetime of shared-cache, in-memory SQLite databases.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Controlling the lifetime of shared-cache, in-memory SQLite databases.

Randall Smith
SQLite has the useful ability to provide an in-memory database that can be shared by multiple connections in the same process by opening the DB with the following syntax:

        rc = sqlite3_open("file:memdb1?mode=memory&cache=shared", &db);

I'm testing a database having this configuration in a unit test framework I have, and I'm finding that when I re-run the unit test, the data in the in-memory DB seems to still be around from the previous unit test run.  This sort of makes sense; the underlying idea here is something else in the same process can (re)-open the database via the same URI.

My questions are:

(a)     Is this right?  A shared-cache, in-memory database is "persistent" across connections from the same process that do not overlap in time?
(b)     Is there some way to reliably blow away one of these databases so I know there will be no hangover state after that operation and can start fresh with a virgin database?

Thanks in advance for any information or ideas.

Randall.


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Controlling the lifetime of shared-cache, in-memory SQLite databases.

Simon Slavin-3

On 28 Apr 2017, at 2:14am, Randall Smith <[hidden email]> wrote:

> (a)     Is this right?  A shared-cache, in-memory database is "persistent" across connections from the same process that do not overlap in time?

Correct.  SQLite doesn’t count connections and do anything special when the number gets back down to zero.

> (b)     Is there some way to reliably blow away one of these databases so I know there will be no hangover state after that operation and can start fresh with a virgin database?

Take a look at

<https://sqlite.org/c3ref/initialize.html>

Calling sqlite3_shutdown() will release all the resources SQLite uses.

Technically, we’re all meant to be calling sqlite3_initialize() and sqlite3_shutdown().  In practise, nobody does because if you forget to initialize the other routines will do it for you, and quitting the process will release everything.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Controlling the lifetime of shared-cache, in-memory SQLite databases.

Clemens Ladisch
In reply to this post by Randall Smith
Randall Smith wrote:
> A shared-cache, in-memory database is "persistent" across connections
> from the same process that do not overlap in time?

No.  <http://www.sqlite.org/inmemorydb.html#sharedmemdb> says:
| The database is automatically deleted and memory is reclaimed when the
| last connection to the database closes.

> ... when I re-run the unit test, the data in the in-memory DB seems
> to still be around
> [...]
> Is there some way to reliably blow away one of these databases so I
> know there will be no hangover state after that operation and can
> start fresh with a virgin database?

Tell your unit test framework to blow away the connection(s).


Regards,
Clemens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Controlling the lifetime of shared-cache, in-memory SQLite databases.

Simon Slavin-3
Errr … Clemens has cites.  I don’t.  Believe him, not me.  Sorry about that.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Loading...