cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <>
Subject RE: Accessing cache validities from flow
Date Tue, 16 Dec 2003 14:15:48 GMT

Christian Haul wrote:
> Stefano Mazzocchi wrote:
> > 
> > Now, the way the event cache works is like this:
> > 
> >  a) a cache validity is generated
> >  b) pipeline is executed
> >  c) result is stored in the cache
> > 
> > then the pipeline is never called, until an event is triggered 
> > externally (from an avalon component) that invalidates that 
> particular 
> > cache entity.
> > 
> > Now, the problem is: if I am not the one who generates the validity 
> > (in linotype, it's the directory generator), how can I 
> invalidate it? 
> > how can I have access to it?
> Not sure if I understand correctly,  so bear with me if this 
> doesn't answer the question at hand.
> The cache component that is event aware can easily be 
> obtained through the component manager. The event name could 
> be set explicitly or determined by convention. In the event 
> cache block there is a EventCacheGenerator that can wrap any 
> other generator to make it produce compliant validities.

Christian is right you can use the EventCacheGenerator for this. It's
not ideal, ugly even, but it works. 

> The CacheEventAction does exactly that to invalidate a cache.
> Of course you could do the same directly from flow.
> The next level is the JMS block. Here, a JMS listener 
> component does the actual invalidating. Hence, any JMS 
> publisher can cause a cache to invalidate. A simpler way is 
> of course to do it through a URL that causes a cache to invalidate.

I was looking at this yesterday. This is SO cool. You could have your
repository running on a dedicated machine and have JMS messages publish
change events that Cocoon running on a different machine will consume.

> Still, there is a problem to solve: Which is the right point 
> for the decision to use the cache? 
> Will the pipeline be 
> assembled and all components have their setup method called 
> or is the validity checked first? 
> Should actions and 
> selectors execute? (probably yes because a different set of 
> components could make up the pipeline) Should setup() be 
> called? (probably no)

Don't know if I am reading you correctly. To me the problem to solve is
where the cache strategy is defined. Or how to overide it in a case such
as event caching. 


View raw message