jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1552) Concurrent conflicting property creation sometimes doesn't fail
Date Wed, 23 Apr 2008 18:37:21 GMT

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

Alexander Klimetschek commented on JCR-1552:
--------------------------------------------

Well, the benefit would be that the client code knows its change is based on obsolete node/property
data, because another session has overridden it in the meantime. But this benefit is debatable.

IMHO it is a good idea to do so, but it needs to be documented. (Generally, there should be
some documentation describing how Jackrabbit works where the spec is open or where Jackrabbit
adds additional features).

Just to add facts, here is the part from the spec about this (7.1.3.3):

    An InvalidItemStateException may be thrown on a write method of an Item
    if the change being made would (upon save) conflict with a change made,
    and persisted, through another Session. If detection of the conflict is only
    possible at save-time, then save will throw an InvalidItemStateException.

This leaves it open for the implementation to throw an exception in this case.

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


Mime
View raw message