Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (athena.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.210.42 as permitted sender)
Received-SPF: pass (google.com: domain of ted.dunning@gmail.com designates
 10.68.194.193 as permitted sender) client-ip=10.68.194.193;
References: <CB75411B.936D%ryan.shelley@email.disney.com>
In-Reply-To: <CB75411B.936D%ryan.shelley@email.disney.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <CCDA460E-B3D0-43A2-933E-72611E9659F3@gmail.com>
Cc: "user@zookeeper.apache.org" <user@zookeeper.apache.org>
From: Ted Dunning <ted.dunning@gmail.com>
Subject: Re: Create nested paths
Date: Thu, 1 Mar 2012 15:25:39 -0800
To: "user@zookeeper.apache.org" <user@zookeeper.apache.org>

Harrumph.=20

The only good thing to say here is that, yes, there is a one to one correspo=
ndence between arguments and results in the returned list.=20

I will have to check the documentation to see if throwing an exception is th=
e correct thing to do for check. It surprises me a bit that you are seeing t=
his result.=20

Sent from my iPhone

On Mar 1, 2012, at 3:14 PM, "Shelley, Ryan" <Ryan.Shelley@disney.com> wrote:=


> Right, I did this:
>=20
> (psuedo-code)
> List<Ops> ops
> For(path in paths)
>  ops.add( Op.check(path, -1) )
> EndFor
>=20
> List<OpResult> Results =3D Zk.multi(ops)
>=20
> This causes an exception to be thrown on the first path that doesn't
> exist. It doesn't return back a list with one OpResult flagged with an
> error. I was under the impression I'd get back a bunch of OpResult objects=

> with flags of error, or otherwise, and then I could build another list of
> operations to create what's needed (which, even if it did work, the
> CheckResult object doesn't include the path, so I'm just hoping the
> results are in the same order as the operations were listed in, as I have
> to infer the path I'll need to build from the position of the OpResult in
> the list).
>=20
>=20
>=20
> On 3/1/12 3:05 PM, "Ted Dunning" <ted.dunning@gmail.com> wrote:
>=20
>> No. I meant one call full of checks and a second call with any necessary
>> creates.=20
>>=20
>> Sent from my iPhone
>>=20
>> On Mar 1, 2012, at 11:17 AM, "Shelley, Ryan" <Ryan.Shelley@disney.com>
>> wrote:
>>=20
>>> Ok, I tried this with the Op.create and found that it will throw a
>>> KeeperException on the first path that doesn't exist. It doesn't return
>>> back an OpResult with an "error" type. I can still use this, and just
>>> catch the exception and create the node in the exception, but I was
>>> under
>>> the impression that I could do this in two trips. One trip to get back a=

>>> list of OpResults from the check that would inform me if the path
>>> existed
>>> or not, and a second trip to create all the paths that don't exist (and
>>> as
>>> a note, the CheckResult object doesn't include the path, so I have to
>>> infer it from the order of my original list of paths used to create the
>>> multi-check).
>>>=20
>>> -Ryan
>>>=20
>>> On 2/29/12 7:16 PM, "Ted Dunning" <ted.dunning@gmail.com> wrote:
>>>=20
>>>> On Wed, Feb 29, 2012 at 7:04 PM, Marshall McMullen <
>>>> marshall.mcmullen@gmail.com> wrote:
>>>>=20
>>>>> Yes, Ted's right. The multi has to fail as that's part of the contract=

>>>>> it
>>>>> guarantees.
>>>>>=20
>>>>> The only thing you could do, which will significantly narrow the race
>>>>> condition, is as you're *building *the multi, check if the path
>>>>> already
>>>>> exists. If so, then don't add the create op for that path into the
>>>>> multi.
>>>>> Of course this may not work in every situation, but we use that
>>>>> approach in
>>>>> many code paths and it works well.
>>>>>=20
>>>>=20
>>>> Another approach is to compose one multi with Op.exists() for each
>>>> level
>>>> so
>>>> that you find everything you need, then create another with the correct=

>>>> Op.create() operations.  That gets the problem down to two server
>>>> round-trips but still has the race condition.
>>>=20
>=20