File‑based vs JDBC snapshots: which preserves linearizable state during concurrent cluster restores?

Neither file-based nor JDBC snapshot stores guarantee cluster-wide linearizable state by themselves. Linearizability in a distributed actor system is a property of the Journal's total order and the Persistence ID, not the storage medium used for snapshots.

Analysis of Snapshot Mechanisms

File-based Snapshots

File-based stores are typically non-transactional and local to a node or a shared filesystem. Because they lack atomic locking mechanisms for concurrent access, restoring them while the system is running risks "torn reads" or inconsistent state application. While stopping the system before restore prevents corruption, it does not synchronize the event sequence across multiple nodes; it only ensures the local node starts from a known state.

JDBC Snapshots

JDBC-backed stores allow concurrent access and provide transactional reads. This means multiple nodes can safely pull the same snapshot without corrupting the database. However, concurrent restoration does not prevent state divergence. If two nodes restore the same snapshot and then replay the journal, they may observe different event sequences if the journal is not globally synchronized or if they reach different high watermarks at different times.

The Core Divergence Risk

The risk of divergent state during concurrent restores is not caused by the snapshot store, but by the replay window. Even if two nodes apply the same snapshot, they will diverge if:

• The journal is not shared or lacks a total order.
• One node completes its journal replay faster than another, leading to a temporary window where the actors observe different states.
• The same Persistence ID is active on multiple nodes simultaneously (a violation of the Akka cluster sharding model).

Verification Steps for Linearizability

To confirm that nodes have converged to the same linearizable state after a concurrent restore, perform the following checks:

1. Sequence Number Audit: Verify that the snapshot sequence number and the final journal sequence number are identical across all nodes for a specific Persistence ID.
2. State Hashing: Calculate a hash of the materialized actor state after replay is complete on all nodes and compare them.
3. Watermark Validation: Ensure all nodes have reached the same journal high watermark before allowing the actor to process new commands.

Required Diagnostic Detail: Are you attempting to restore the same Persistence ID on multiple nodes simultaneously, or are different nodes restoring different actors from a shared store?