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)" <[email protected]> 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:[email protected]] > |Sent: Friday, December 12, 2008 2:24 PM > |To: Mahadev Konar > |Cc: [email protected] > |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" <[email protected]> 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" <[email protected]> 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" <[email protected]> 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 > |>
