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