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.
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.
I have a similar question. Hope you could clarify!
After calling the Resolvers, the Commit proxy can race when writing to the log system because there is multiple Commit proxy.
So even if calling the Resolver guarantee that the commit version reflect a serializable ordering of the transaction there is still one problem.
one transaction TX2 in commit proxy #2 could get commit Version = 2 and finish writing to log before another transaction TX1 on proxy #1 with commit version = 1.
This way a new transaction TX3 started after TX2 would get ReadVersion= 2 and possibly see some or none of the change made by transaction TX1 while seeing all changes made by transaction TX2.
one transaction TX2 in commit proxy #2 could get commit Version = 2 and finish writing to log before another transaction TX1 on proxy #1 with commit version = 1.
This won’t happen. Commit version (CV) is obtained from the Sequencer with the previous commit version (PCV). So TX2 has (CV, PCV) pair of (2, 1). Similarly, TX1 has (CV, PCV) pair of (1, 0). On any log server, it will persist these two transactions in the order of TX1, and TX2, i.e., in the monotonically increasing order of CVs. When TX2 reaches a log server, the server can only persist TX2’s data when the PCV=1 is already received and written. If not, the log server’s processing of version 2 waits for version 1.
If a proxy get stuck, after 20s, the proxy detects this and kills itself, which then triggers recovery. After recovery, the DB becomes available again.
