hesela.devStrict serializability
Strict serializability requires committed transactions to be equivalent to a serial execution that preserves real-time precedence between non-overlapping transactions.
Serializability alone omits real-time precedence. Linearizability is the special case of one operation on one object per transaction. Separate reads do not automatically constitute a transaction. The property constrains committed histories, not observations from aborted transactions. [1]
A transaction completed before another begins must precede it in the serial order. The companion analysis illustrates the difference using two records, not a database experiment. [1]
In etcd v3.6, RangeRequest.serializable=true selects member-local reads that may lag consensus. Selecting an explicit historical revision asks a different question from reading current state; neither option turns an arbitrary client sequence into a transaction. [3]
etcd documents durability separately. Its watches are revision-ordered but not linearizable, and a request timeout can leave the outcome unknown. Ordering does not imply a watch delivery deadline or safe repetition of a non-idempotent operation. [2]
Relations
Advantages
- A transaction begun after another completes cannot be serialized before it. [1]
Limitations
- The guarantee covers the specified transaction scope, not arbitrary separate requests or external side effects. [1, 2]
- Durability and recovery after failures require separate guarantees. [2]
Citations
- Herlihy and Wing. Linearizability: A Correctness Condition for Concurrent Objects. ACM TOPLAS 12(3), 1990, sections 2.2 and 3.3 (p. 473).
- etcd v3.6 API guarantees: Strict serializability, Durability, Watch APIs and Operation completed.
- etcd v3.6 API reference: RangeRequest revision and serializable fields; TxnRequest.
Further reading
Sources & caveats
- Definition and illustrative history derived from Herlihy and Wing sections 2.2 and 3.3; no benchmark or empirical consistency test.
- etcd implementation claims are scoped to v3.6 documentation; an overlapping linearizable read need not include every write completed before its response.