jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: Concurrent modifications
Date Wed, 23 Apr 2008 11:23:02 GMT
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

Mime
View raw message