Alexander Klimetschek wrote:
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.
Well, the normal update cycle is *getting* the content, modifying it,
then writing it back. To be useful, that's the sequence of operations
that needs to be supported, right?
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.
It would.
I've tried it, and it doesn't seem to make a difference.
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.
I can try that, but believe me, that wasn't the goal of this exercise.
Wild guess: maybe something was broken when
<https://issues.apache.org/jira/browse/JCR-584> was addressed?
Shouldn't we have test cases for this kind of stuff???
BR, Julian
