jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1552) Concurrent conflicting property creation sometimes doesn't fail
Date Thu, 24 Apr 2008 14:19:22 GMT

    [ https://issues.apache.org/jira/browse/JCR-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592076#action_12592076

Thomas Mueller commented on JCR-1552:

Jackrabbit should either always or never throw an exception. When concurrently updating or
adding properties, that is. 'Never throw an exception' seems easier. Also the implementation
is faster, that's why I would prefer that.

If we decide to 'always throw', then the algorithm could be as follows: whenever a session
reads, re-reads, transiently modifies, or adds a property, remember the old version (timestamp
or data). When calling save, check if the current persistent state matches the old timestamp
or data.

When concurrently updating or adding nodes (so far I was talking about properties only), the
same algorithm can be used. One problem is the following use case:

Node b = a.hasNode(x) ? a.getNode(x) : a.addNode(x);

With multiple threads / sessions you end up with same name siblings sometimes. That's probably
not what the user wants. This is not an issue for properties as there is no 'addProperty'
method. I don't know if there is a solution for nodes without using locks. For SQL databases,
one solution is using the MERGE statement (sometimes called UPSERT from INSERT or UPDATE).

> Concurrent conflicting property creation sometimes doesn't fail
> ---------------------------------------------------------------
>                 Key: JCR-1552
>                 URL: https://issues.apache.org/jira/browse/JCR-1552
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: core 1.4.2
>            Reporter: Thomas Mueller
>            Assignee: Stefan Guggisberg
>             Fix For: 1.5
> The following test prints "Success":
>        Session s1 = ...
>        Session s2 = ...
>        s1.getRootNode().setProperty("b", "0"); // init with zero
>        s1.getRootNode().setProperty("b", (String) null); // delete
>        s1.save();
>        s1.getRootNode().setProperty("b", "1");
>        s2.getRootNode().setProperty("b", "2");
>        s1.save();
>        s2.save();
>        System.out.println("Success");
> However  if the line marked "... // delete" is commented out, 
> it fails with the following exception:
> javax.jcr.InvalidItemStateException:
> cafebabe-cafe-babe-cafe-babecafebabe/{}b: the item cannot be saved
> because it has been modified externally.
>        at org.apache.jackrabbit.core.ItemImpl.getTransientStates(ItemImpl.java:246)
>        at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:928)
>        at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:849)
> It should fail in all cases. If we decide it shouldn't fail, it needs to be documented.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message