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
[EMAIL PROTECTED]
>> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
