huh, we should use our APIs more. ;-)

Ben can you open a jira on this? Mark it fix for 3.1.0.


Benjamin Reed wrote:
I looked into this a bit more since i remembered that the protocol
returns the stat structure. it turns out to be a bug in the C API. in
java, both the sync and async version of setData will give you a stat
structure back. in C, zoo_aset uses the stat_completion_t, so you get
the stat structure back. unfortunately zoo_set() does not return the
stat structure. i think we should open a bug on this.


________________________________________ From: Avery Ching
[] Sent: Friday, December 12, 2008 12:41 PM To:
Patrick Hunt Cc: Subject: Re:
zoo_set() version question

I am working on clusterlib (YST project) and we are using zookeeper
for a backing store of cluster abstractions (i.e. Applications,
groups, nodes, data distributions, etc.).

I believe that this is an optimization use case for using zoo_set()
with versions that are != -1.


1.  I do a successful zoo_set() with version V, where V != -1. 2.
Make more changes to my data. 3.  I want to do another zoo_set() but
I don't know what version number to try.

Since I don't know the version number I have to use either
zoo_exists() or zoo_get().  Even though zoo_exists() gets me the
version number I don't know whether that version is the one that I
wrote.  Therefore I need to read the znode (zoo_get()) and compare
with the data that I did set before I make changes to the data (step
2) ) that I will zoo_set in step 3).  Note that I am never sure if I
was the last writer.

If there is a way to get the used version from zoo_set(), then I do
not need to use zoo_exists() or zoo_get() in between zoo_set() calls
(steps 1) and 3) ).  They will still fail, of course, if the version
is wrong.  And the other benefit is that I will know that I was the
last writer if I get the version from my last successful zoo_set()
and then do zoo_exists() and the versions match.


On 12/12/08 11:53 AM, "Patrick Hunt" <> wrote:

Could you explain your use case? There is no way to get the version
as part of a zoo_set, however there may be some alternative that we
can suggest if we knew more about the problem you are trying to


Avery Ching wrote:

Thanks for responding.

I agree that I can use zoo_exists and zoo_get to get the version
of the znode as it exists currently.

The problem I am trying to solve is that getting the version from
struct Stat in either zoo_exists or zoo_get may not be the same
version that my last successful zoo_set used.  I would like to
get the version that denotes my last successful zoo_set()
operation to a particular znode.

I understand that the data and version to the znode may change
immediately one or multiple times after my zoo_set() and this is
fine, but I would still like to know the znode's versions of the
data I set.


On 12/12/08 11:11 AM, "Patrick Hunt" <> wrote:

Avery Ching wrote:
If zoo_set() completes successfully with version != -1, can
we assume that version -> version + 1 for this znode?  If
not, is there a way for the user to get the version of the
successfully completed zoo_set() operation?
You shouldn't rely on this, it may work, but it's not part of
the contract. Also, nothing says that some other client won't
change the node immediately after you change it.

You can access the version using zoo_exists or zoo_get -
specifically the "struct Stat stat" argument of either of those
methods contains a "version" member.


Reply via email to