A space held in memory

IN MEMORY keeps a space's keys in the node's memory only — no log, no disk, no backup, empty after a restart — for the data a cache server holds.

Sessions, rate counters and hot lookups are data you would rather lose than pay a disk sync for. IN MEMORY keeps a space's keys in this node's memory and nowhere else:

DEFINE NAMESPACE app;
USE NAMESPACE app;
DEFINE DATABASE web;
USE DATABASE web;
DEFINE SPACE hot IN MEMORY MAX 100000;
SET hot:'session:ada' = 'signed-in' EXPIRE 30m;
INCR hot:'hits';
GET hot:'session:ada';

'signed-in'. Everything a space does still works: transactions, INCR, conditional SET, expiry, MAX and EVICT NONE, KEYS walks, and the lists, hashes, sets and rankings.

What it gives up

The definition is ordinary catalog: it is replicated, backed up and kept across a restart. The keys are not:

a write takes no log record and no disk sync, so it costs a fraction of a durable write;
no follower receives it, and no backup or script dump carries it;
a restart empties the space.

MAX n is required, and a declaration without it is refused where it is written (expected MAX n — a space held in memory states how many keys it may hold), because a space in memory with no limit is a node that runs out of memory. The limit counts keys, as it does for any space.

A transaction cannot write a held space and anything durable together:

DEFINE SPACE ledger;
BEGIN;
SET hot:'k' = 1;
SET ledger:'k' = 1;
COMMIT;

InMemoryBesideDurable. The two writes would not survive a restart together, so the store does not let them commit as one.

On a cluster

A held space belongs to the leader of its range, as every write does. That is one copy, in that node's memory, which every client sees.

A write or a read sent to another node is carried or redirected to the leader (WriteIsElsewhere, ReadIsElsewhere). No other node holds any of the keys, so an answer there would pass for an empty space. A failover starts the space empty on the new leader, as a restart does.

A namespace more than one node may write (MULTI MASTER) has no single owner for a held space, and a write to one is refused as InMemoryOnACluster.

DROP SPACE frees the space's memory as soon as the drop commits, or when the last transaction that began before it ends.

When to use it

A space declared IN MEMORY is the right home for the keys a RESP client keeps in a cache server. Point --resp-space at it, and the client gets the same speed and the same loss on a restart that it was built for, now inside the database's transactions.