jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Concurrent addNode (Was: [jira] Commented: (JCR-1552) Concurrent conflicting property creation sometimes doesn't fail)
Date Thu, 24 Apr 2008 17:51:53 GMT

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.


Jukka Zitting

View raw message