Make it invisible.

The shared token and the version field both detect a tear: the read pulls both values back, compares them, and reacts to a mismatch. The torn pair still reaches the caller, and the caller has to repair it. A commit marker changes the order of operations so the incomplete pair never reaches a read at all. Write every data key first. Then, as a separate final step, write one extra key that records the decision to commit:

The ordering is the whole mechanism. Phase 1 places the data; phase 2 publishes it. Until the marker key exists, the data keys are present but uncommitted. A reader does not touch the data keys until it has confirmed the marker: EXISTS txn:abc:committed is the gate — a 1 means phase 2 completed, a 0 means the transaction is incomplete and the data is treated as absent:

If the writer dies after phase 1 but before phase 2, the data keys exist — possibly torn, A new and B old — but the marker does not. The gate returns 0, the read never touches the half-written pair, and the incomplete transaction is invisible. A crash after phase 2 is a complete transaction by definition: every data key and the marker are present, so the gate returns 1. The EX 3600 bounds the marker's lifetime so abandoned records do not accumulate without bound.

The pattern resembles two-phase commit, with the marker acting as the decision record. Phase 1 is the prepare: stage every value, commit to nothing. Phase 2 is the single write that flips the whole transaction from prepared to committed. It is a shape, not a full protocol — there is no coordinator forcing all participants to commit, no rollback that removes the staged data, and the marker write is itself a single key that can fail. What it buys is a clean visibility rule across keys that cannot share a slot.

The same partial-failure timeline reads two ways. A bare shared token from the first dive is a detector: the read fetches both values, parses both tokens, and on a mismatch returns a torn pair the caller must repair. A commit marker is a gate: the read checks EXISTS …:committed first and, finding it absent, returns nothing. Detection exposes the tear and pushes the recovery onto the reader; the marker hides the tear and removes the recovery step entirely. The comparison table in the source places them side by side — a transaction stamp buys detect only, a commit marker buys detect plus visibility. Run the one timeline through both:

EchoMQ does not write a commit marker on its own queue transitions, because the transition it would gate is already atomic in one step. A queue's keys share one slot (the {q} hashtag in EchoMQ.Keyspace.queue_key/2), so the whole move is one inline Lua script. EchoMQ.Jobs.complete/4 (jobs.ex:313) hands Connector.eval/5 the @complete script (jobs.ex:139) over two declared keys — KEYS[1] the active set, KEYS[2] the job row:

That whole sequence — the fencing check, the ZREM off the active set, the DEL of the row — is one EVAL. It is visible-or-not in a single step: the job is retired in full, or EMQSTALE is returned and nothing changed. There is no half-written pair to gate, so there is nothing for a commit marker to do. The v2 law that makes this one step safe is in Connector.eval/5 (connector.ex:63): every key the script touches is declared in KEYS, so the engine keeps them on one slot and runs the move as a unit.

A commit marker reorders the writes so the incomplete pair is never read: write the data, then one final marker, and read only what EXISTS confirms. It hides the tear where a token or a version exposes it, at the cost of one extra key and a round trip. EchoMQ needs none of it: the single Lua EVAL over co-located keys is the serialization point, visible-or-not in one step. Return to the module hub for the prevention comparison, or to the Coordination chapter for R2.05.