jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: Concurrent modifications
Date Tue, 22 Apr 2008 18:37:55 GMT

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
alexander.klimetschek@day.com

 >> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<





Mime
View raw message