[
https://issues.apache.org/jira/browse/JCR-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592051#action_12592051
]
Jukka Zitting commented on JCR-1552:
------------------------------------
Stefan:
> 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).
But there's no reliable way (short of explicitly locking the node) for session2
to know whether the property already existed. The InvalidItemStateException is
typically not a reliable indicator of this case as a concurrent thread could
just as well already have saved the changes before session2 called
setProperty(), making the operation an update instead of a create with session2
being none the wiser.
> this is IMO a regression since i am pretty sure it used to throw an
> InvalidItemStateException in the past.
Again, IMHO it's rather an improvement.
> 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).
These cases are IMHO not equivalent. Creating a child node is like a INSERT
statement in a database, where as setting a property is more like an UPDATE
statement on an existing row. Concurrently creating two child nodes with the
same name is like two database clients trying to INSERT a row with the same
primary key -> the other one should fail. But concurrently setting a property
is more like two clients executing an UPDATE on the same row. Unless there's an
isolation level violation there's no reason why both clients shouldn't succeed,
even if a column was NULL or either one of the clients sets it to NULL.
> 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.
