jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller" <thomas.tom.muel...@gmail.com>
Subject Re: Concurrent modifications
Date Wed, 23 Apr 2008 12:22:06 GMT
Hi,

I have had similar problems recently. I have now a test case:

    public static void main(String[] args) throws Exception {
        Repository repository = new TransientRepository();
        Session s1 = repository.login(new SimpleCredentials("", new char[0]));
        Session s2 = repository.login(new SimpleCredentials("", new char[0]));
        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");
        s1.logout();
        s2.logout();
        System.out.println("End");
    }

As is, the code prints "Success" "End" for me.
If the line marked "... // delete" is commented out, it fails with the
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)
	at Test.main(Test.java:33)
Exception in thread "main"

It's a bit strange that it works in one case but not the other.

The second problem is that the application doesn't exit (some threads
are still running). Is this the expected behavior? If not I will log a
bug about that.

Regards,
Thomas

On Wed, Apr 23, 2008 at 2:11 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
>
>  On Wed, Apr 23, 2008 at 3:06 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
>  > So, to make this useful, a client would need to re-read the property value
>  > before, checking it's still the same as earlier on? Is that the proposal?
>
>  Re-reading won't help as another session could still make changes
>  before the save.
>
>  My suggestion is that the client should use an explicit lock if it
>  needs such synchronization.
>
>  BR,
>
>  Jukka Zitting
>

Mime
View raw message