Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <42617802.9090403@jboss.com>
Date: Sat, 16 Apr 2005 22:39:30 +0200
From: Julien Viet <julien@jboss.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: jackrabbit-dev@incubator.apache.org
Subject: Re: Getting "custom" objects from the repository?
References: <181174235.20050416061620@freemail.hu>
 <426119F3.4060809@jboss.com> <1916674571.20050416201707@freemail.hu>
In-Reply-To: <1916674571.20050416201707@freemail.hu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

ok for 1/ but 2/, isnt the notification synchronous ? (even if the spec 
does not mandate it).


Daniel Dekany wrote:

>Saturday, April 16, 2005, 3:58:11 PM, Julien Viet wrote:
>
>  
>
>>invalidate the cache :
>>
>>- time based invalidation, you say that an entry is valid for 1 minute
>>for instance
>>- notification, you can use JCR observations mechanism to remove entries
>>from the cache
>>    
>>
>
>Neither works. As I said "Of course no hazards and unpredictable delays
>are allowed after the repository was modified", and it can't be achieved
>with asynchronous event notifications and time based invalidation. It's
>so obvious that I guess it was not clear what I meant with "no hazards
>and unpredictable delays", so let me tell a simple example: You have an
>MVC web application, and for each page visit you use script (like a
>Jython script) and a HTML template. These are from the Web application
>point of view mycms.Script objects (stores the pre-parsed (compiled)
>script) and mycms.Template objects (stores the pre-parsed template), and
>from the JCR point of with nodes (maybe of type mycms:template and
>mycms:script). These object are seldom changed, but if they are, you
>have certain expectations. Assume I start transaction, modify a script
>and a template in the repository, and then commit the transaction. Now,
>when you start a new transaction later (e.g. for satisfying a HTTP
>request), you want to see the new objects, not the old ones, especially
>if you want to check what you have just committed. Also, you don't want
>to face with inconsistent states, where for example the script object is
>in its old state, and the template object is in new state (since in
>general the old template works correctly only with the old script, and
>the new template works correctly only with the new script, and mixing
>the two will result in error 500 pages and other malfunctions). It's
>basically the same as the ACID thing of the RDBMS-es, and surely I don't
>need to explain why is this absolutely important for server side
>applications. Now, on the JCR level everything is "ACID" (well, it can
>be if transactions are supported etc). But you will seldom use raw JCR
>without some kind of object mapping behind it, right? And if all the
>"ACID" loses with the object mapping (as the cache can't be kept
>precisely in sync with the content of the repository), then in practice
>you have just trashed the ACIDity of the JCR repository. Does anybody
>get what I'm saying? You have to modify sites while they are running...
>think about a big "portal", so you need that ACID very much.
>
>  
>
>>cheers
>>
>>Daniel Dekany wrote:
>>
>>    
>>
>>>I suppose most applications want to work with objects like mycms.User,
>>>mycms.PageTemplate, myapp.Book, etc., rather than directly with the tree
>>>of items that JCR shows. I don't see what's the intended way of doing
>>>this. With a concrete example: I would like to store page templates in
>>>the repository, which are complex and frequently used objects, so they
>>>shouldn't be recreated from a binary property (or from string string
>>>property, whatever) every time they are read from the repository (that
>>>is, for each page hits). I could use cache in front of JCR that caches
>>>the template objects, but how to ensue that the cache is in sync with
>>>the repository? Of course no hazards and unpredictable delays are
>>>allowed after the repository was modified.
>>>
>>>What's the planned way of doing things like this?
>>>
>>>(I know this is not a Jackrabbit but a JCR question and I apologize for
>>>that, but I didn't found a more suitable public list.)
>>>      
>>>
>
>  
>


-- 
Julien Viet
JBoss Portal Lead Developer