Possibility of stale reads


I just read the FoundationDB paper and had a followup question for my own understanding.

Is it possible for the following scenario to occur? Basically, some transaction T2 receives a read version (11) from the sequencer, but still reads a stale version (some version < 10) of a key X. The read is stale because there is some concurrent transaction T1 which writes to X with commit version 10, but that has not finished being resolved and sending its data to the log system by the time T2 tries to read from the storage system.

Screen Shot 2022-04-12 at 3.36.26 PM

Probably I’m misunderstanding something here. I’d appreciate any help with my confusion!

T2 won’t read the stale version from the storage system, because the read is version 11 associated with it. The storage server receives the read and looks for key X at version 11. If the version is not present, the storage server knows it’s not up-to-date and waits until version 11 is available or return an error (then the client can retry with a different storage server replica).

The contract of FDB is that once a read version 11 is available, data for version 11 and all previous versions have persisted on the log system. So storage servers will eventually (typically very quickly) have all data up to version 11.