jackrabbit-dev mailing list archives

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

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

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

View raw message