zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Reed <br...@yahoo-inc.com>
Subject Re: Atomic Compare-and-swap like operations
Date Tue, 18 Jan 2011 17:59:16 GMT
it would be nice if it could be folded in, it does create a problem 
though. the issue is that only reads do not go through the atomic 
broadcast, so in some recovery cases it would be hard to get the old 
data back. it's not that in can't be done, but i think it significantly 
complicates the design.

it seems like the easiest way to do this would be to have the 
delete-and-return operation so that the old data is explicitly put in 
the recovery log. if we do delete-and-return, we probably also want 
set-and-return :)


On 01/15/2011 01:43 PM, Ted Dunning wrote:
> I think that the multi stuff is the ideal place for this kind of capability.
>   To do this, we would need to add a get operation to the current collection.
>   I think that would be an excellent addition, not only for your use case but
> also the one where you want to get consistent copies of several znodes at
> once.
> On Sat, Jan 15, 2011 at 8:14 AM, Scott Fines<scottfines@gmail.com>  wrote:
>> It seems like it would be a very powerful option to be able to have a
>> "delete-and-return" operation that atomically deletes a znode, and returns
>> the bytes that were previously stored in that znode. Is there a particular
>> reason why this was not chosen as the behavior of the API? In most of the
>> other generic compare-and-swap operations (put-if-absent and
>> set-if-matches), there is already a mechanism in place, or one can
>> relatively easily be implemented, but this seems like an odd oversight.
>> I saw that ZooKeeper-965<
>> https://issues.apache.org/jira/browse/ZOOKEEPER-965>
>> could
>> potentially address this in the future, but it seems like API overkill for
>> something like this.

View raw message