zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shelley, Ryan" <Ryan.Shel...@disney.com>
Subject Re: Create nested paths
Date Thu, 01 Mar 2012 23:14:40 GMT
Right, I did this:

List<Ops> ops
For(path in paths)
  ops.add( Op.check(path, -1) )

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
>Sent from my iPhone
>On Mar 1, 2012, at 11:17 AM, "Shelley, Ryan" <Ryan.Shelley@disney.com>
>> 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
>> 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
>> or not, and a second trip to create all the paths that don't exist (and
>> 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
>>>> 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
>>> 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.

View raw message