Re: zoo_set() version question
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)" wrote: > Most probably we shouldn't explicitly state the increment count but that > it will increase. Also is there a rest/overflow condition ? > Cheers > > > |-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" 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" 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" 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 > |>
RE: zoo_set() version question
Most probably we shouldn't explicitly state the increment count but that it will increase. Also is there a rest/overflow condition ? Cheers |-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" 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" 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" 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 |>
Re: zoo_set() version question
If I can get the version number from zoo_set(), it doesn't really matter from my point of view that the version number is always += 1, only that it is increasing. Avery On 12/12/08 2:24 PM, "Patrick Hunt" wrote: > 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" 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" 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" 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 >>
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" 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" 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" 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
Re: zoo_set() version question
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" 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" 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" 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 >>
Re: zoo_set() version question
huh, we should use our APIs more. ;-) Ben can you open a jira on this? Mark it fix for 3.1.0. Patrick 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. ben From: Avery Ching [ach...@yahoo-inc.com] Sent: Friday, December 12, 2008 12:41 PM To: Patrick Hunt Cc: zookeeper-user@hadoop.apache.org 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. I.e. 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. Avery 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 solve. Patrick Avery Ching 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" 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
RE: zoo_set() version question
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. ben From: Avery Ching [ach...@yahoo-inc.com] Sent: Friday, December 12, 2008 12:41 PM To: Patrick Hunt Cc: zookeeper-user@hadoop.apache.org 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. I.e. 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. Avery 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 solve. > > Patrick > > Avery Ching 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" 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 >>
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. I.e. 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. Avery 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 solve. > > Patrick > > Avery Ching 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" 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 >>
Re: zoo_set() version question
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" 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" 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
Re: zoo_set() version question
Also I am assuming that you are not using version = -1. -1 means that it overrides the data on that node. mahadev On 12/12/08 12:12 PM, "Mahadev Konar" wrote: > Hi Avery, > If you are using zoo_set( , int version), > > And you have a success, then the version of the node that denots your > successful zoo_set() above is > = Version +1 > > Are you using it to keep track of what revision is the one valid for your > set's? > > > mahadev > > On 12/12/08 11:36 AM, "Avery Ching" 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" 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 >>
Re: zoo_set() version question
Hi Avery, If you are using zoo_set( , int version), And you have a success, then the version of the node that denots your successful zoo_set() above is = Version +1 Are you using it to keep track of what revision is the one valid for your set's? mahadev On 12/12/08 11:36 AM, "Avery Ching" 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" 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 >
Re: zoo_set() version question
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 solve. Patrick Avery Ching 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" 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
Re: zoo_set() version question
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" 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
Re: zoo_set() version question
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
