Hi,

how do in-memory databases work?

I create a database using
Session.Execute('CREATE DATABASE MemDB IN MEMORY');
in my code.

Where ist this DB stored? I can see it in the ElevateDB Manager even after a reboot of the computer. So in which memory does it live?

Burkhard


The database lives in either the server's memory or the local PC's memory.

Roughly speaking an in-memory database is exactly the same as a disk based one its just that the "disk" happens to be in RAM rather than on HDD.

Unlike HDD table definitions and data do not persist when the process (think application) is terminated. I generally prefer to use in-memory tables rather than temporary ones since they are guaranteed to clean themselves up when I close a program.

There are differences between precisely how in-memory tables are accessible between c/s & f/s - generally the difference shouldn't matter, but it has been discussed in these forums and in the release notes.

Roy Lambert

Burkhard,

<< how do in-memory databases work?

I create a database using
Session.Execute('CREATE DATABASE MemDB IN MEMORY');
in my code.

Where ist this DB stored? I can see it in the ElevateDB Manager even after a reboot of the computer. So in which memory does it live? >>

To add to what Roy described:

1) In-memory databases are not session-specific, and are process-wide.  This means that they can be shared across multiple sessions/threads.

2) Because they are process-wide, their lifetime is the same as the process, provided that they are not dropped prior to the process terminating.  For the EDB Server, this means that an in-memory database will, for all intents and purposes, act just like a normal database for the lifetime of the EDB Server process.  The only difference being that the data is completely in-memory.

The in-memory databases in EDB can be very useful for storing things like session information for web server applications, or any other type of non-persistent data that needs to be shared among multiple sessions/threads.

Tim Young
Elevate Software
www.elevatesoft.com

Tim


>1) In-memory databases are not session-specific, and are process-wide. This means that they can be shared across multiple sessions/threads.

This, I think, is what I was referring to with the differences between c/s & f/s. I'm running off memory of something I've read on the forums but never used so could be totally wrong, but if not its an important point. In f/s the process is the application running on the user's PC. In c/s mode the process is EDBServer running on the server PC.

A consequence of this is that using f/s its safe to have a single name for an in-memory table used by every user and there will be no collisions. In c/s that isn't true and IF you want to keep separation between users you need to create each in-memory table with a different name.

I forget when this behaviour was introduced, previously in-memory tables were isolated to the session creating them not the process. In my case that was what I wanted even for c/s so all my in-memory tables get created with a tablename based on GetTickcount.

Roy Lambert