Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of jukka.zitting@gmail.com
 designates 74.125.46.28 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=eie2lTUHuEQDnTPyF604p/vLZUdRreohkxXUxQcSs2lXXq9/54g/iKa+2WK7cqaSlI1mSjk0yOMjCFhn9SequzGAzIh4GZ4+Va1K23w5/8WLuBukER2kYh6/0vvvJmfvHQ7jK+yZdW0Prk8gEKagf3FXJwM0lIjK63Hupv45bq4=
Message-ID: <510143ac0804241051y5e886d01v86657b3db354bcc7@mail.gmail.com>
Date: Thu, 24 Apr 2008 20:51:53 +0300
From: "Jukka Zitting" <jukka.zitting@gmail.com>
To: dev@jackrabbit.apache.org
Subject: Re: Concurrent addNode (Was: [jira] Commented: (JCR-1552) Concurrent
 conflicting property creation sometimes doesn't fail)
In-Reply-To: <5f211bd50804241041o6d81e20fmb3b64f5d2ac669f9@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <510143ac0804241029g514e2c5eqa9a5fd312df17233@mail.gmail.com>
	 <5f211bd50804241041o6d81e20fmb3b64f5d2ac669f9@mail.gmail.com>

Hi,

On Thu, Apr 24, 2008 at 8:41 PM, Thomas Mueller
<thomas.tom.mueller@gmail.com> wrote:
>  >  The best solution IMHO is not to allow SNS in the first place.
>
>  Yes, unfortunately it's not the default behavior. And making it the
>  default would break XML import.

Sure, but if you're (or your application is) concerned about this,
it's fairly easy to disable SNSs.

>  >  Another solution would be a custom getOrAddNode() method, like the one
>  >  I've implemented
>
>         try {
>             return parent.getNode(name);
>         } catch (PathNotFoundException e) {
>             return parent.addNode(name, type);
>         }
>
>  Uhm, looks a bit ugly, and still doesn't always work with multiple
>  threads (two threads can't get the node, both will create one)? Or do
>  you mean something else?

Sure, it's not as nice as it could be, but it works in practice. I'm
using this in a non-SNS case (nt:folder), so the worst that can happen
is the addNode (or the following save) failing with an
InvalidItemStateException. And that's fine as those cases are quite
rare (reasonable naming) and the surrounding application (email) will
just automatically retry the operation a bit later.

I could have used a JCR lock for this, but in this case the benefit is
not necessarily worth the trouble.

>  It's probably a bit late to add an atomic getOrAddNode into JSR-283 I
>  guess... But we could add it to the Jackrabbit API anyway if we want
>  to.

We already provide the locking mechanism for clients that care about
such things, so perhaps a utility mechanism in jcr-commons would be
more appropriate.

BR,

Jukka Zitting