In-Memory-Snapshot-Store

InMemorySnapshotStore hält Snapshots in einer Map<persistenceId, Snapshot[]> im Prozess-Speicher. Wie InMemoryJournal ist es der Default, wenn kein Snapshot-Store konfiguriert ist — null Setup, ideal für Tests, niemals in Produktion verwenden.

import { ActorSystem, ActorSystemOptions } from 'actor-ts';
import { InMemoryJournal, InMemorySnapshotStore } from 'actor-ts/persistence';

// In-Memory-Stores sind der Default; hier explizit gezeigt:
const actorSystemOptions = ActorSystemOptions.create().withPersistence({
  journal:       new InMemoryJournal(),
  snapshotStore: new InMemorySnapshotStore(),
});
const system = ActorSystem.create('demo', actorSystemOptions);

Was es tut

Implementiert das SnapshotStore-Interface — save, loadLatest, loadBefore, delete. Jede persistenceId mappt auf ein Array von Snapshots, geordnet nach Sequenznummer.

• save(persistenceId, seq, state, options?) — in das Array der pid einfügen und einen vorhandenen Eintrag mit derselben Sequenznummer ersetzen.
• loadLatest(persistenceId, options?) — den Snapshot mit der höchsten seq zurückgeben oder None.
• loadBefore(persistenceId, seq, options?) — den neuesten Snapshot mit sequenceNr < seq zurückgeben oder None.
• delete(persistenceId, toSeq) — Snapshots mit seq ≤ toSeq abschneiden.

Die Implementierung ist Referenz-Semantik — jeder andere Snapshot-Store muss dieses Verhalten erfüllen (modulo Persistenz- / Verschlüsselungs- / Kompressions-Spezifika).

Aufbewahrung

keepN begrenzt, wie viele Snapshots pro persistenceId behalten werden; ältere werden beim Speichern entfernt. <= 0 behält alle.

import { InMemorySnapshotStore, InMemorySnapshotStoreOptions } from 'actor-ts/persistence';

const inMemorySnapshotStoreOptions = InMemorySnapshotStoreOptions.create().withKeepN(3);
const snapshotStore = new InMemorySnapshotStore(inMemorySnapshotStoreOptions);

Ohne Angabe behält er jeden Snapshot — und das ist die eine Stelle, an der dieser Store bewusst von der Familie abweicht, in der jeder persistente Store keepN: 3 als Default hat. Dies ist der Store, den du bekommst, wenn nichts konfiguriert ist; ein Default-Limit würde also ändern, was jede unkonfigurierte Anwendung aufbewahrt, ohne dass jemand danach gefragt hat. Entscheide dich stattdessen explizit dafür.

Erneutes Speichern unter einer bereits vorhandenen Sequenznummer ersetzt diesen Snapshot, statt einen zweiten anzuhängen — passend zum Primärschlüssel (persistence_id, sequence_nr) der relationalen Stores.

Wann verwenden

• Tests — schnell, kein IO, sauberer Teardown pro Test.
• Dev — wenn du keine echte Snapshot-Datei zwischen Runs herumliegen haben willst.
• Referenz für benutzerdefinierte Implementierungen — lies den Source für den Vertrag.

Wann NICHT verwenden

Produktion

Daten sterben mit dem Prozess. Ein Neustart verliert jeden Snapshot, sodass die Recovery jedes Mal auf vollständigen Event-Log-Replay zurückfällt — was den Sinn von Snapshots zunichtemacht.

Lange laufende Tests

Snapshots akkumulieren standardmäßig im Speicher. Ein Benchmark, der über einen Run 1M Snapshots macht, lässt die Map linear wachsen. Für lange Tests setze keepN, rufe delete selbst auf oder verwende den SQLite-Store mit :memory:.

Wie geht’s weiter

• Snapshots — die Policy / Mechanik.
• SQLite-Snapshot-Store — Single-Node-Produktion.
• Cached-Snapshot-Store — wickle jeden Store mit einem In-Process-Cache ein.