cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <a.schrijv...@hippo.nl>
Subject RE: Caching question
Date Sat, 14 Jan 2006 19:25:57 GMT

> 
> Thanks for the input.  One thing that can be done is two come up with 
> algorithms you would like and then create a new pipeline classes to 
> implement them.  I would assume they would be a variation on the 
> CachingProcessingPipeline.  That is exactly how you would 
> accomplish the 
> graphcche pipeline below.
> 
> FWIW, in our site a changing file on the filesystem would 
> need to be an 
> event.

Well, the difficulty is that changing a file on filesystem of course does not fire an event
like a JMS message. The way cocoon does it now is something as follows:

A request matches a pattern which has an aggregate....cocoon is instantiating (I call it this,
I don't know how it works with pooling and stuff, so forgive me for that) all "child pipes"
to determine all keys. One of the child pipes depends on a filesystem xml file which is changed,
so after checking of the validity of this file, the cache key is removed, and cocoon regenerates
that particular child pipeline etc etc...

So if we somehow want the aggregator cache key to know enough by only looking at its onw key,
and changing a file on filesystem does not raise an event, then, there only remains a cron
job checking for its keys the validities, and when it find one that is not valid anymore,
through some graph parent pipelines aer invalidated as well. 

But I don't like the idea about cron jobs doing checks...you can imagine. Other then this,
I would not know how to accomplish it. Most changes of sites we build come from changes in
a repository, where a jms message is send to invalidate depending dasls and repository files.
That makes it less harder then for filesystem

Ard

> 
> Ralph
> 
> Ard Schrijvers wrote:
> 
> >Perhaps the subject should be: Caching problems with cocoon. 
> >
> >
> >For example, <map:pipeline type="graphcache"> where the 
> graphcache implies that it keeps track of dependencies. That 
> also means, that changing a file on filesystem is not an 
> event, so it won't be invalidated. Is that a problem, well, 
> not if a site is deployed....after deployment, the 
> filegenerator does not have to check the validity of a file: 
> I know it is valid.
> >
> >I know it possibly won't fit in cocoon easy, but making 
> complexer sites and wanting to exploit the caching in cocoon 
> effectively, there has to be some smarter caching invalidation. 
> >
> >What I found the weirdest of all, was that for an expiring 
> pipeling, you can actually set the expire time and the exact 
> cache key it should use, so it can be unambigously found when 
> the pipeline is called again, that it still checks all child 
> pipeline keys (which again can be very expensive). 
> >
> >These were just my two cents on cocoon caching...
> >
> >Regards Ard
> >
> >
> >  
> >
> 

Mime
View raw message