The role of CAS in a durability poll?
tl;dr: 2x CAS Stores in a row for same key, durability polling replication for both, will the first one _always_ succeed?
I recall reading somewhere in the docs that multiple successive writes to a single key won't cause each one to be persisted to disk. This optimization makes sense, but that kind of behaviour is what's making me wonder what the roll of CAS in a durability poll is. Note that even though I did just mention persistence, I really am only interested in replication (so if there's a difference...).
resp = storeWithCas("keyX", value); //succeeds
storeWithCas("keyX", value); //succeeds
...so if both of those processes are run at the same time (and they retry with exponential backoff should one affect the other), will both of those durability polls succeed?
Going back to the persistence analogy, I know it to be true that whichever value is stored first 'probably' won't be written to disk. So since replication and persistence are handled similarly in Couchbase ("eventual"), does that also mean that the first value set 'probably' won't be replicated (causing the durability poll to fail)???
I would try to test this, but it's a race condition so eh...
Understanding how durability_poll works requires understanding of the lcb_observe command. Basically durability_poll will _only_ be able to count items which contain the same CAS as exists in the master. Its role is twofold:
(1) If the item exists in the _master_ with a different CAS, durability_poll returns an error immediately saying LCB_KEY_EEXISTS, which in this case means something else has overwritten this item.
(2) If the item exists in the replicas and does _not_ have the same CAS the respective nodes are omitted from the check as it is assumed those nodes contain a potentially older copy of the item.
The reason why (1) does not automatically use the 'new CAS' from the master is because at this point the master may have changed from the time when you originally set the key (i.e. you failed over the master and a replica took over). In this scenario the different CAS in the current master's cache might not be from a newer mutation but possibly from an older mutation.