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 > >
