A pure-Erlang, in-memory dgen_backend.

Implements the FoundationDB semantics the registry actually depends on — MVCC read versions, read-conflict detection, versionstamps, watches — with no NIF, no server, and no I/O. Two things follow:

• The suite runs without FoundationDB installed. Worth having on its own.
• Commit timing stops being a source of nondeterminism, which is the last one outside eta_sched and eta_time. Commits happen synchronously, in the calling process, in a deterministic order.

Fidelity, and where it stops

Key layout is exactly FDB's: erlfdb_subspace and erlfdb_tuple are pure Erlang, so this reuses them rather than reimplementing order-preserving tuple encoding, where a subtle error would surface as ordering bugs in dgen_queue.

What is modelled faithfully:

• Read versions. A read sees the newest value written at or before the transaction's read version. Pinning a read version (set_read_version/2) really does read the past, which is what makes the registry's fencing test meaningful.
• Read conflicts. A commit aborts with not_committed (1020) if any key in a read-conflict range was written after the transaction's read version. This is the mechanism the leader fence rests on (§5.1), so it has to be real.
• Versionstamps. set_versionstamped_value/3 substitutes a 10-byte stamp — 8-byte commit version, 2-byte in-transaction batch order — so the registry's version key decodes and orders exactly as it does against FDB.
• Watches. A watch fires when its key is written by a later commit.

What is not:

• No storage-level partitioning, no coordinators, no real distribution. A simulation runs in one VM, so the database is a single serialisation point rather than a cluster that can partition beneath the system under test.
• Write conflicts are not tracked. FDB conflicts a commit whose write set overlaps another transaction's read set. Here commits are serialised, so the losing transaction is simply the one that commits second, and it sees the other's writes. Nothing in dgen depends on the distinction.
• No transaction size limit (transaction_too_large). Nothing in dgen approaches FoundationDB's 10MB transaction cap.
• No retry backoff. FoundationDB backs off exponentially with jitter; transactional/2 here retries at once, up to 100 attempts. A timer:sleep/1 would be wrong under a virtual clock — a sleeper is neither runnable nor blocked on a receive, so eta_sched can never step it.

The MVCC window is modelled. Versions advance at FoundationDB's rate (VERSIONS_PER_SECOND = 1e6) and the window is the same version distance (MAX_READ_TRANSACTION_LIFE_VERSIONS, 5 seconds' worth), so a read older than the window raises transaction_too_old as it would against the real thing — and under a virtual clock those five seconds are reachable instantly.

The version rate follows whatever clock eta_time exposes, so start the clock before opening the database; doing it part-way through shifts the origin the rate is measured from.

Fault injection

set_faults/2 makes the failures the registry is built to survive reproducible: conflict_p (spurious not_committed, which a correct caller retries) and commit_fail_p (a non-retryable error). Both draw from a seeded RNG, so a run replays.

Determinism

State lives in ETS keyed by the database handle and nothing runs in a process of its own, so no call into this module can read as quiescence to eta_sched. Commit versions come from a counter, not a clock.

This documentation is LLM-generated. See the AI disclosure in README.md.