But how would a client of SharedValue know they had the latest "base" value on which to compute an update value? You would try to change the value and, if it returns false, you read the value again.
Since I wrote my email, I found DistributedAtomicValue which has the API I would have expected. Cool -JZ On October 1, 2014 at 3:57:25 PM, Scott Blum ([email protected]) wrote: But how would a client of SharedValue know they had the latest "base" value on which to compute an update value? Since I wrote my email, I found DistributedAtomicValue which has the API I would have expected. On Wed, Oct 1, 2014 at 4:11 PM, Jordan Zimmerman <[email protected]> wrote: SharedValue keeps a copy of the last version that was read. trySetValue() uses the version to set the value. This is a feature of ZooKeeper. It allows for optimistic locking. If the version matches, the update succeeds. Otherwise it fails. -JZ On October 1, 2014 at 3:08:04 PM, Scott Blum ([email protected]) wrote: I've been staring at SharedValue for the last 15 minutes and I can't figure out how it works. Naively, I don't see how it's possible to safely implement trySetValue(newValue). Wouldn't it have to be compareAndSetValue(oldValue, newValue)? I'm imagining client code that looks like this: byte[] currentValue = sharedValue.getValue(); byte[] newValue = operationOn(currentValue); sharedValue.compareAndSetValue(currentValue, newValue); The only way to write this right now (unless I'm missing something) is: byte[] currentValue = sharedValue.getValue(); byte[] newValue = operationOn(currentValue); sharedValue.trySetValue(newValue); The problem is, an update can happen in between the call to getValue() and trySetValue(), and the way the code's written, SharedValue doesn't record read accesses, so it has no idea if any user code actually called getValue() "recently". Am I missing something? Scott
