Maybe you guys are right! If we are returning the stat we should not
explicitly state it. As long as we don't have a dire need for it, we
shouldn't make it a guarantee on zookeeper.

@krishna,
 the count does overflow. Its an int. the calculation we did was that even
if we have 100 processes updating a node 10,000 times a day, it would take
around 5 years before you overflow the int.


mahadev


On 12/12/08 3:07 PM, "Krishna Sankar (ksankar)" <ksan...@cisco.com> wrote:

> Most probably we shouldn't explicitly state the increment count but that
> it will increase. Also is there a rest/overflow condition ?
> Cheers
> <k/>
> 
> |-----Original Message-----
> |From: Patrick Hunt [mailto:ph...@apache.org]
> |Sent: Friday, December 12, 2008 2:24 PM
> |To: Mahadev Konar
> |Cc: zookeeper-user@hadoop.apache.org
> |Subject: Re: zoo_set() version question
> |
> |That's fine, but we should document it. Please enter a JIRA that the
> |docs should talk about this.
> |
> |I notice we have this in the prog guide:
> |"Each time a znode's data changes, the version number increases."
> |
> |Sort of a moot point once we fix the zoo_set api but we should
> |explicitly state that it increments by 1.
> |
> |Patrick
> |
> |Mahadev Konar wrote:
> |> That's right pat. I thought about that. Though ben already mentioned
> |that we
> |> missed the stat return in the c sync code.
> |> But for the version, since its a test and set, we should also
> |guarantee that
> |> the version is a +1 to prev one. It would be really unintutive if it
> |was
> |> otherwise.
> |>
> |> Also I noticed after ben's comments that the async callback
> zoo_aset()
> |is
> |> called back with stat argument. Only the zoo_get() sync api is
> missing
> |stat
> |> return code :).
> |>
> |>
> |> mahadev
> |>
> |> On 12/12/08 12:39 PM, "Patrick Hunt" <ph...@apache.org> wrote:
> |>
> |>> Mahadev Konar wrote:
> |>>> And you have a success, then the version of the node that denots
> |your
> |>>> successful zoo_set() above is
> |>>>  = Version +1
> |>> Mahadev, that's the current implementation, but I wasn't aware we
> |were
> |>> exposing that detail as something users should rely on. Is it
> |documented
> |>> anywhere in the docs? If this is "user visible" we should document
> |it, I
> |>> thought we weren't exposing this for a reason...
> |>>
> |>>>
> |>>> mahadev
> |>>>
> |>>> On 12/12/08 11:36 AM, "Avery Ching" <ach...@yahoo-inc.com> wrote:
> |>>>
> |>>>> Patrick,
> |>>>>
> |>>>> 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.
> |>>>>
> |>>>> Avery
> |>>>>
> |>>>> On 12/12/08 11:11 AM, "Patrick Hunt" <ph...@apache.org> 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.
> |>>>>>
> |>>>>> Patrick
> |>

Reply via email to