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 Tue, 22 Apr 2008 18:17:00 GMT
Alexander Klimetschek wrote:
> Hi Julian!
> 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).

> 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 
> ;-)

It is :-)

Changing the test as suggested doesn't affect the result; still no 
exception.

BR, Julian

Mime
View raw message