You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently given implementation of this cluster manager contains lots of code that first reads an entry and then update or remove it - sort of CAS operation which is not synchronized by consul agent.
Imagine a scenario where entry is being read by Alice in order to get replaced (or removed or updated) and in the meanwhile Bob wants to update same entry and he actually does. Bob's write takes place before Alice proceeds which means Alice's read value is not consistent anymore with central storage. Question: Are we allowing Alice's write forcibly to take place or should we come up with something like
CAS;
entry locking;
applying consul transactions;
to abort Alice's write ? It has to be investigated.
The text was updated successfully, but these errors were encountered:
Currently given implementation of this cluster manager contains lots of code that first reads an entry and then update or remove it - sort of CAS operation which is not synchronized by consul agent.
Imagine a scenario where entry is being read by Alice in order to get replaced (or removed or updated) and in the meanwhile Bob wants to update same entry and he actually does. Bob's write takes place before Alice proceeds which means Alice's read value is not consistent anymore with central storage. Question: Are we allowing Alice's write forcibly to take place or should we come up with something like
to abort Alice's write ? It has to be investigated.
The text was updated successfully, but these errors were encountered: