Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (nike.apache.org: domain of marshall.mcmullen@gmail.com
 designates 209.85.212.170 as permitted sender)
Received-SPF: pass (google.com: domain of marshall.mcmullen@gmail.com
 designates 10.204.156.129 as permitted sender) client-ip=10.204.156.129;
MIME-Version: 1.0
In-Reply-To: <CCDA460E-B3D0-43A2-933E-72611E9659F3@gmail.com>
References: <CB75411B.936D%ryan.shelley@email.disney.com>
	<CCDA460E-B3D0-43A2-933E-72611E9659F3@gmail.com>
Date: Thu, 1 Mar 2012 23:28:20 +0000
Message-ID: 
 <CAOVjqTq-cMtJKyiv+6VMNuO+M4J+aCnAZx535XCVAnJ8nfQHLw@mail.gmail.com>
Subject: Re: Create nested paths
From: Marshall McMullen <marshall.mcmullen@gmail.com>
To: user@zookeeper.apache.org
Content-Type: multipart/alternative; boundary=000e0ce0275ac9a21e04ba36d00c

--000e0ce0275ac9a21e04ba36d00c
Content-Type: text/plain; charset=ISO-8859-1

Check is just handled the same as the other ops. In the
PrepRequestProcessor stage if the requested path doesn't exist, then it
aborts the multi with an error.

On Thu, Mar 1, 2012 at 11:25 PM, Ted Dunning <ted.dunning@gmail.com> wrote:

> Harrumph.
>
> The only good thing to say here is that, yes, there is a one to one
> correspondence between arguments and results in the returned list.
>
> I will have to check the documentation to see if throwing an exception is
> the correct thing to do for check. It surprises me a bit that you are
> seeing this result.
>
> Sent from my iPhone
>
> On Mar 1, 2012, at 3:14 PM, "Shelley, Ryan" <Ryan.Shelley@disney.com>
> wrote:
>
> > Right, I did this:
> >
> > (psuedo-code)
> > List<Ops> ops
> > For(path in paths)
> >  ops.add( Op.check(path, -1) )
> > EndFor
> >
> > List<OpResult> Results = Zk.multi(ops)
> >
> > 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).
> >
> >
> >
> > On 3/1/12 3:05 PM, "Ted Dunning" <ted.dunning@gmail.com> wrote:
> >
> >> No. I meant one call full of checks and a second call with any necessary
> >> creates.
> >>
> >> Sent from my iPhone
> >>
> >> On Mar 1, 2012, at 11:17 AM, "Shelley, Ryan" <Ryan.Shelley@disney.com>
> >> wrote:
> >>
> >>> 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).
> >>>
> >>> -Ryan
> >>>
> >>> On 2/29/12 7:16 PM, "Ted Dunning" <ted.dunning@gmail.com> wrote:
> >>>
> >>>> On Wed, Feb 29, 2012 at 7:04 PM, Marshall McMullen <
> >>>> marshall.mcmullen@gmail.com> wrote:
> >>>>
> >>>>> Yes, Ted's right. The multi has to fail as that's part of the
> contract
> >>>>> it
> >>>>> guarantees.
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>
> >>>> 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.
> >>>
> >
>

--000e0ce0275ac9a21e04ba36d00c--