Am 22.04.2008 um 20:17 schrieb Julian Reschke:
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
Actually, it *is* fetched before (in the assertEquals).
Yes, but it is fetched for read only.
What I actually meant is fetched *and* modified, but not yet saved.
This is the way something goes into the transient space - at least in
Jackrabbit's implementation. AFAIK.
Changing the test as suggested doesn't affect the result; still no
exception.
Ok, this comes as a surprise. Maybe it's different when you actually
get the Node and its Property as object? Like this:
// modify property in session 1's transient space
Node content = n1.getNode("jcr:content");
Property prop = content.getProperty("jcr:data");
prop.setValue(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();
But this would be quite awkward.
Another reason might be that you are using a binary property
("jcr:data"). These are handled differently inside Jackrabbit because
they tend to be large and are stored in the DataStore for example.
(Although this should only apply for larger ones...). Maybe you could
try to test with a simple DOUBLE property instead.
Alex
--
Alexander Klimetschek
[EMAIL PROTECTED]
>> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
