Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> Create nested paths

Copy link to this message
Re: Create nested paths
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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> wrote:
>> On Wed, Feb 29, 2012 at 7:04 PM, Marshall McMullen <
>> [EMAIL PROTECTED]> 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.