[
https://issues.apache.org/jira/browse/JCR-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592043#action_12592043
]
Stefan Guggisberg commented on JCR-1552:
----------------------------------------
> Jukka Zitting commented on JCR-1552:
> ------------------------------------
>
> I don't understand why any of these examples should fail with an
> InvalidItemStateException. It would make sense if we supported higher
> isolation levels where already getProperty() would "freeze" the property
> state, but since we don't do that (and I think it's good that we don't) I
> fail to see the benefit of this.
>
this particular issue is about the special case where 2 sessions are both
*creating* a new property with the same name, using interleaved save calls.
session2 in my example is not aware that it actually overwrote an existing
property (lost update problem). this is IMO a regression since i am pretty sure
it used to throw an InvalidItemStateException in the past.
this special case can be compared with the scenario where 2 sessions are
creating conflicting child nodes (SNS not allowed). in this case the
implementation does throw an exception (which is IMO not only correct but also
mandated by the spec).
> 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.
