hesela.devConcurrent prefix recovery
Concurrent prefix recovery identifies durable operation prefixes separately for each client session rather than by one global issue-time cutoff.
The 2019 protocol chooses the session boundaries jointly; independent arbitrary cutoffs are not a substitute for its consistency protocol. [1]
API boundary: FasterKV documents a commit point with UntilSerialNo and optional excluded pending operations. An exception below the frontier is not durable merely because its number is small. [2]
Waiting for durability: the pinned WaitForCommitAsync implementation checks the frontier and an empty exclusion list, completes pending synchronous operations and requires asynchronous operations to have been awaited. It does not initiate a checkpoint itself. [3]
The linked Hesela example accounts for invented operation identities; it does not execute FASTER or prove checkpoint consistency. [4]
Relations
- related
- Hybrid log, Database checkpoint, Group commit
Limitations
- The paper's checkpoint protocol and the documented exception-bearing API must not be treated as identical abstractions. [1, 2]
Citations
- Prasaad, Chandramouli and Kossmann. Concurrent Prefix Recovery: Performing CPR on a Database. SIGMOD 2019, sections 2, 4.3 and 7; DOI 10.1145/3299869.3300090.
- FasterKV Checkpointing and Recovery: session commit points and pending-operation exceptions; documentation dated 6 May 2021.
- FASTER ClientSession.cs, commit 332ea7da532a688acf648ee60c4f63a1caeaf1f7, WaitForCommitAsync lines 955-984.
- Hesela: recovery receipts, exception holes and replay accounting.
Sources & caveats
- Historical protocol and documented API reviewed separately; no implementation execution or performance reproduction.