Probably what you want is to achieve a compare and swap with serializable reads and writes in a normal transaction.
There is a mutation called COMPARE_AND_CLEAR, which is kind of similar but the problem is that if the value of the key is not what’s expected at commit time, the transaction still commits successfully and the COMPARE_AND_CLEAR mutation has no effect. Generally people seem to want the transaction to fail with not_committed in this case, but the only way to get a transaction to fail if the value of a key is unexpected at commit time is to read the key [1]. You can see some more explanation about why we can’t easily know the result of the atomic mutation here: Efficient way to create if absent in FDB.
Hope that helps. Let me know if I can clarify anything.
-
Depending on your data model, it’s possible that you can infer the value of a key at your transaction’s read version without actually reading it, and in that case you only need to add a read conflict on that key. Be sure to add the read conflict before modifying the key - see Adding an explicit read conflict range skips the keys in write cache · Issue #126 · apple/foundationdb · GitHub for a discussion of why. ↩︎