zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ketan Gangatirkar <ke...@indeed.com>
Subject Re: Accessing previous versions of znode data
Date Fri, 01 Jul 2011 15:33:50 GMT
Seems like what you want are sequential nodes.  Instead of storing the
data directly in /configuration/whatever, you store the most recent
configuration in a sequential node under that path:

/configuration/whatever/0001
/configuration/whatever/0002
/configuration/whatever/0003
...
Instead of directly reading a single node, you get the list of
children and then read from the newest one.  Your watch will be on
changes to the children, not on the contents of the node.  The number
of the node indicates which version it is.

There's still a narrow window between listing the children and getting
the newest one where you might get data that are slightly out of date.
 If it's super important to avoid that, you can invalidate a node when
you create a new one by doing a redundant write to the old one.  That
will increment its version number but keep the same contents.  Then
when you read a configuration node that has version 1, you know it's
not the newest one so you retry.  The redundant write and creation of
a new node would have to happen in the same multi-op (coming in
3.4.0).  Alternately, you could might be able to replace the redundant
write with an ACL change.


On Fri, Jul 1, 2011 at 10:21 AM, Burgess, Jason
<Jason_Burgess2@cable.comcast.com> wrote:
> Greetings!
>
> After doing several searches on this list, as well as going through the documentation
and code, I've come to the conclusion that it is not possible to access the data associated
with a specific version number for a particular znode. Am I correct?
>
> For those wondering, here is my use case:
>
> We are looking to store configuration in the znode (usually less than 10KB) and using
Watches to notify the entities that are being configured that a new configuration is available.
However, we may run into an instance where a faulty configuration is stored on the znode,
and we would like to go back through the previous versions until we reach a valid configuration,
or we have no more configs.
>
> Thanks!
>
> jason
>



-- 
Ketan Gangatirkar
ketan@indeed.com
Perishable Developer

Mime
View raw message