I think what I was getting at was a flag that simply says "It's ok to already exists, just ignore it and continue." However, I'm doing the approach you already suggested and checking each sub-path before adding the Op to the list, and it works fine. I just wanted to make sure I wasn't missing a better approach. Thanks!
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.
