jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: refresh method or version stamp
Date Sun, 17 Apr 2005 21:09:24 GMT
> >> >> - jcr:modificationCounter which is automatically created and
> > just to understand your architectural approach:
> > if i understand you correctly you would then in your
> > "cache-system" check that property "jcr:modificationCounter"
> > before serving anything from your cache. is that correct?
> Yes.
> > and that means that the jcr client would on every access to
> > your cache ask the "repository server" about the value of
> > that "jcr:modificationCounter" over network? is that correct?
> Exactly. And, the jcr:uuid, otherwise it worth nothing.
??? i don't understand. ???

> > on every read operation to your cache?
> You see, it is still far better than getting jcr:content on every read
> operation (which supposedly a long string or binary), then create a
> mycms.Template or org.w3c.dom.Document or etc from it, for each occasion
> when you read it.
i think you are missing a whole lot. 
what does jcr:content have to do with your mycms.template?
were you going to extend your mycms.template from nt:file? 
and if yes, why? i would have seen that as a properly structured 
mycms:template nodetype.
btw. you realize that a modification of a property or 
property of a child node does not automatically 
modify parent node.

> > is that really what you suggest?
> Yes, but it was not really a proposal or something like that. Simply,
> there is a task that can't be avoided (IMO), i.e. this sync-ed cache
> must be implemented *somehow*, because of the use-cases explained during
> this thread. If anybody has a better idea, tell it. 
for the use case that you describe i think an asynchronous 
observation listener is just fine. 

i don't see why it is of utmost importance that the
cache of your mycms.template is updated in a transactional 
fashion with the back end. practically, i can't even come up 
with a drawback of async cache invalidation for a template cache. 

as a matter of fact we implement in our own commercial 
cms (which powers some of the worlds most high-profile 
websites) the template cache invalidation though asynch 
observation. works perfectly fine.

i would agree, that in other cases, it may be desirable to have 
synchronous triggering of events to solve the caching issues in a 
transactional fashion, which is exactly what we use in jackrabbit 
wherever we require it.

the network overhead that you encounter with your "polling"-solution
is ridiculous compared to (synch or asynch) observation considering 
that you stated earlier that the cached information changes very 
rarely and is read very frequently. 

> In fact I have asked
> for a solution originally, with the optimistic assumption 
> that the Expert Group who has developed JCR has considered 
> this obvious use-case.
we used those exact use-cases to try to argue to 
keep synchronous observation it in the spec. 
maybe i was not clear before, the synchronous observation
has been removed from the spec (it was completely speced 
out in the beginning) because of variety of unresolved
technical questions for existing non-java repository 
vendors.

nevertheless every repository implementation is free 
to support synchronous observation, and you seem to 
be in luck since jackrabbit does ;)

regards,
david

Mime
View raw message