Read-Write Conflict

(AJPham) #1

I don’t understand Read-Write conflict in blog

I demo and the results are not like result of the blog pos


(Ron Arévalo) #2

Hey @AJPham,

Sorry for the delay here.

Can you let us know what the difference was between your tests and our blog post?




(Andrei Matei) #3

You may be referring to this paragraph from the read-write conflicts section:

All write operations consult the timestamp cache for the key they are writing; if the returned timestamp is greater than the operation timestamp, this indicates a RW conflict with a later timestamp. To disallow this, the operation (and its transaction) must be aborted and restarted with a later timestamp.

That blog post is ancient. Since it was written, we’ve done all sorts of work to eliminate various transaction retries. In particular read-write conflicts don’t necessarily encounter restart if we manage to “refresh” the writer’s read-set (if we manage to prove that the writer’s read-set has not changed since it originally read the data that it read, then we don’t need to restart). There’s also other mechanisms that sometimes kick in to hide transaction retries from the client when they are still needed.