Stability level

Current stability level for Memory Store:

Beta 1
Beta 2
RC Stable
Visit here to report an issue or request a feature enhancement.

Back To Top


JXcore provides you with a fast and efficient in-memory storing capabilities. We call it Memory Store.

It’s implementation is based on Google’s cpp-btree library, hence benefits from it’s advantages.

The major performance benefit from Memory Store is very high access speed (even for large containers) and low memory foot-print. Indeed, the best news is, that Memory Store is kept outside V8′s heap memory space. As a result it doesn’t fall under it’s limitations (similar to Multithreaded isolates). Keeping V8 away from high memory pressure also results in more responsive application since the unexpected garbage collection may keep the application blocked several seconds.

The Memory Store works like a standard key/value store. It is available for both main and sub threads and also as a separate or shared object.

When used in multithreading, every sub-instance has it’s own object. It can be considered as a static global per store context, which means, that sub-instances cannot share the same among themselves. But all of the tasks running inside a particular sub-instance have shared access to it.

In some scenarios you may need a single store, which you could access from any sub-instance. Use object for this purpose. You should be aware of the following principles, even if all operations on this store are thread-safe. First of all, access time may take little longer comparing to the single instanceded especially when using operations, which modify content of the data store (set(), remove() and get() – the last one also removes the item). Also, when different sub-instances are simultaneously writing/modifying value of the same key, the final stored value is the one that is updated last.

Thread-safe has exactly the same methods as single instanced

Back To Top

How it works?

The Memory Store internally keeps all values as strings. You can also save other primitive value types (numbers, booleans), but they will be automatically converted to strings. For any other types, like objects or arrays – the conversion has to be done by you.

Storing the value:

// string"myKey", "my value");

// number, will be stored as string "3.14""myKey", 3.14);

// boolean, will be stored as string "true""myKey", true);

// object
var obj = { val1: "one", val2 : 2, arr : [ 3, 4, 5] };"myKey", JSON.stringify(obj));

When the object is written to the Memory Store, the value is copied into a memory space completely separated from what is used by V8. Thus, you can even delete the object on the javascript side, so it can be handled by the garbage collection:

obj = null;

Don’t worry, you still have your copy in a safe place.
Whenever you want to take it back, simply call one of the:

var copy ="myKey");
// or
var item ="myKey");

The difference between read() and get() is that get() also removes the key and value from the store. For more information, please refer to the api documentation.

Please keep in mind that at the moment when you read() the object, you have 2 instances of it in the memory: one is still kept in Memory Store, and the second one (result from the read() method) resides in V8′s memory block.

If you use large strings, you may not want to keep the duplicates. For this purpose you can use directly get(), which will remove the value from the store.

Back To Top