3 ms·
I understand how a fencing token can prevent out of order writes when 2 clients get the same lock. But what happens when those writes happen to arrive in order
by reza_n 11y ago
I understand how a fencing token can prevent out of order writes when 2 clients get the same lock. But what happens when those writes happen to arrive in order and you are doing a value modification? Don't you still need to rely on some kind of value versioning or optimistic locking? Wouldn't this make the use of a distributed lock unnecessary?
- Terr_ 11y ago> But what happens when those writes happen to arrive in order and you are doing a value modification? I believe the "first" write fails, because the token being passed in is no longer "the lastest", which indicates their lock was already released or expired.
- querulous 11y agoif your tokens come from a linearizable source (like zookeeper) you can do a compare-and-set to mutate state safely. you read the state, perform your mutations on it, then in an atomic transaction read the state again and if it is the same as the initial state save your new state. if your fencing token is the highest yet seen the service uses your state as the authorative state. if it's not it rejects the change