Write a non-conflicting value in a read transaction.
Reads are linearizable by default, including read-only transactions. Can you share more about exactly what you’re worried about?
I have the same wrong as this topic, I want clients to be able to read the latest value after another client modifies the key instead of stale read.
My personal favorite hack is to add a write conflict range of a random safe key (\xfe\xff\xff\xff or something), as that’s cheaper than adding an actual write. All transactions can use the same key, you just want it to be some key that no client will ever try to read.
However, there’s very few circumstances I’ve seen where an application requires a read to be serialized as of the commit() call instead of at the getReadVersion() call. If you’re able to share your use case, we’d be happy to help reason about it, or provide other potential workarounds.
I’m very sorry, I may have some wrong understanding of linearizable read. For the situation mentioned by Topic, linearizable read is satisfied, and commit read-only transaction can be said to ensure higher consistency.
bro, Is my current understanding correct?
The only thing you gain by adding a synthetic write conflict and committing an otherwise read only transaction is that (if the commit is successful) your reads are valid at commit time [1].
The reason this isn’t very useful is that the key can change immediately after your transaction commits, just like it can change immediately after your transaction begins. IMO it’s much easier to reason about if you simplify perform the reads again in a new transaction instead of committing.
There’s an important distinction between the “commit time” of your transaction and the “commit version” of your transaction. FDB commits transactions in batches, and transactions later in a batch occur after transactions earlier in a batch in the global ordering. Suppose T1 and T2 commit in the same batch, in that order. It could be that T1 reads key K, and T2 writes key K, and there would be no conflict since the write to K occurs after the commit time of T1. Both T1 and T2 get the same commit version, which identifies the contents of the database after applying the effects of T1 and T2 in order. This means that if you read key K in T1, and you re-read key K at the commit version of T1, you cannot expect to see the same value you read in T1. If you want something that provides a global ordering (even within a batch), then you can use a version stamp, but you can’t read the contents of the database at a particular version stamp since the effects of the entire batch are applied atomically. ↩︎