Hi Julian!

Am 22.04.2008 um 19:04 schrieb Julian Reschke:
>    // modify through session1
>
>    n1.getNode("jcr:content").setProperty("jcr:data", testcontent +  
> ", as modified by session 1");
>    n1.save();
>
>    // modify through session2
>
>    n2.getNode("jcr:content").setProperty("jcr:data", testcontent +  
> ", as modified by session 2");
>    n2.save();
>  }

I think it's correct. The property "testconcurrent/jcr:content/ 
jcr:data" in session 2 is never put into the transient space *before*  
session 1 saves. It is fetched for the first time when you modify it.  
That you have done it above while creating the properties for the  
first time is irrelevant, since you did a save() then, which took  
those properties "out" of the transient space again.

IIUC this is an example of the "copy-on-write" style that Jackrabbit  
implements. See "7.1.3.4 Seeing Changes Made by Other Sessions" in the  
JSR-170 spec.

It should only throw an exception if you did this:

    // modify property in session 1's transient space
    n1.getNode("jcr:content").setProperty("jcr:data", testcontent + ",  
as modified by session 1");

    // modify persisted property through session 2
    n2.getNode("jcr:content").setProperty("jcr:data", testcontent + ",  
as modified by session 2");
    n2.save();

    // now try to save session 1... should fail
    n1.save();


Please note that the above statement is purely theoretical at the  
moment ;-)

Regards,
Alex

--
Alexander Klimetschek
alexander.klimetschek@day.com

 >> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<