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. >
