cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: forced caching of volatile data
Date Wed, 20 Aug 2003 19:04:52 GMT
I apologize if I've already mentioned this, but I think there are some 
different angles on solving your problem which you may want to consider.

One is implemented in part in the event-cache block but it could be 
generalized to work for any component.  Unico Hommes wrote a Generator 
(in that block, but don't know its name) which uses a Delegation pattern 
to wrap any other arbitrary Generator.  It delegates all interface 
methods to the wrapped generator except for the get Validity (and 
currently the key as well, but I think that might need to change.  He 
then uses a factory which specifies how to construct the overridden 
validity.  The plan was to generalize this to work with any component. 
Hope that makes sense.

The second possibly simpler solution is to create a new pipeline 
implementation that always caches.  So, when you have a pipeline that 
should be forced to cache, you segregate it into its own map:pipeline 
section with a parameter that speficies how long to cache.

A third is to consider the event based cache stuff itself.


Gianugo Rabellino wrote:
> Sorry for the late reply. Vacation time + lousy GPRS + heavy spam/worm 
> activities nearly killed my ability to read email.
> Miles Elam wrote:
>> I'm running into a snag and was wondering if anyone had some wisdom to 
>> grant to me.  The current behavior of caching pipelines is to 
>> aggregate the keys of all cacheable pipeline components and use them 
>> as the cache hash lookup.  In the case of a pipeline that has 
>> uncacheable components but has an expiry, this scheme doesn't work: 
>> the key is incomplete or nonexistent.  My first thought was to use the 
>> request URI but therein lies the snag;  Any actions or selectors in 
>> use that would fundamentally alter the request would be erroneously 
>> cached.  In 90% of the cases, I don't see this as a problem.  But in 
>> cases like when different formats are sent to different clients for 
>> the same URI
> Yes, this was exactly my showstopper when I tried to quickly force 
> caching uncacheable stuff. I really need to catch up on caching 
> internals as it's been a few months since I looked at it, but I was 
> kinda of planning to add a fake cache key for each component in the 
> pipeline which is uncacheable. The problem is coming up with a syntax 
> that is reversible, so that the resulting key can be successfully looked 
> up.
> The trick should lie somewhere in 
> o.a.c.components.pipeline.impl.AbstractCachingProcessingPipeline#generateCachingKey():

> there should be, in particular, some kind of surrogate that returns a 
> key for each non cacheable component. I'm still uncertain whether this 
> key should be unique (based, i.e., on the positional parameter of the 
> component in the sitemap) or if a simple label could work. I'm for the 
> latter ATM: of course I need to check it out, but the following snippet 
> (extended to transformers & serializer) might work.
>         // is the generator cacheable?
>         if (super.generator instanceof CacheableProcessingComponent) {
>             key = ((CacheableProcessingComponent)super.generator).getKey();
>             this.generatorIsCacheableProcessingComponent = true;
>         } else if (super.generator instanceof Cacheable) {
>             key = new Long(((Cacheable)super.generator).generateKey());
>         } else if (expires != 0) {
>             // Component is not cacheable, but an explicit expires
>             // was set. Provide a fake cache key.
>             key = new String("Forced-Expires");
>         }
> Doing so, we would end up with a PipelineCacheKey that's made up of 
> different caching keys, some of which are real and some of which are 
> just placeholders. I'm going to try this path and see what comes out of it.
> Ciao,

View raw message