cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Airey <>
Subject Re: Caching for database driven sites
Date Tue, 14 May 2002 15:16:09 GMT
Hello Steven, 

First let me say that I am not a developer of cocoon, but a developer
who uses cocoon, so it's possible that I have something wrong here. If
so, anyone please feel free to correct me. 

This code works with the released version, cocoon2.0.2

Additionally, I am running all of this in the context of a
jboss/catalina environment

I have a similar requirement to programmatically invalidate a cache of a
particular pipeline from an action in a different pipeline. Search the
mail archives for "programmatic invalidation" for the thread. 

Anyway, I am happy to say that I have now got programmatic invalidation
working as follows:

Here is the definition of the generator which I wrote

   <map:generator name="user" src="com.ihm.generators.UserGenerator"
                        pool-max="32" pool-min="8" pool-grow="4"/>

Here is the pipeline I want to invalidate:

   <map:match pattern="user">
     <map:generate type="user"/>
     <map:serialize type="xml"/>

There are other pipelines which call this pipeline using a file
generator (like the one below), and then a cinclude transformer.

<?xml version="1.0"?>
<page xmlns:cinclude="">
  <cinclude:include src="cocoon:/roles"/>
  <cinclude:include src="cocoon:/user"/>

Here is the code which invalidates the "user" pipeline:


Store store= (Store) manager.lookup(Store.TRANSIENT_CACHE);

// first remove the cached generator output
PipelineCacheKey userPCKey = new PipelineCacheKey();

ComponentCacheKey ccKey;
ccKey = new ComponentCacheKey(ComponentCacheKey.ComponentType_Generator,
            "user", // Shortname of generator to invalidate.
            getUserId().longValue());  // key to invalidate


// remove generator cache

PipelineCacheKey transPCKey= new PipelineCacheKey();

ccKey= new ComponentCacheKey(ComponentCacheKey.ComponentType_Serializer,
           "xml", // Shortname of serializer to invalidate.
           1);    // 1 is hardcoded as the key of this serializer

// now we have the key to get the cached object. We could get it if we
// CachedEventObject cachedObject = (CachedEventObject)store.get(pcKey);


* Delete this pipeline: generator + serializer.  This is not used from
* other pipelines, but is used if the output of the user pipeline is
* streamed straight to a browser.  Therefore in production this pipeline
* will probably never be used, but we'll invalidate it just in case.


As a side note, in my testing of this code, it seemed that the generator
cache only was used when the pipeline was called from internally, ie
"cocoon:/user", but the generator+serialiser pipeline was called if the
pipelie was called externally, ie from a browser

I *speculate* that if the pipeline is just gen+xml_serialiser, and is
called internally, then the include transformer omits the serialiser as
an optimization step.

A final note is that you can find the cached values serialised to disk
in "cocoon-files/cache-dir" somewhere under catalina/work under the same
name as the PipelineCacheKey.toStringValue (once instantiated). However,
they're only serialised on application shutdown/undeploy.


On Tue, 2002-05-14 at 14:56, Steven Sedlmeyer wrote:
> We are evaluating porting an existing CMS and web publishing system over to
> cocoon but we have some issues with caching.  In our particular situation we
> normally use two different cache management strategies:
> 1.  For automated feeds (newswires etc.) we use a time based expiration 
> 2.  For Editor generated or managed content we generate events from the
> database that cause content to be uncached when it is changed.  This, in our
> system, includes page layouts, articles, navigation and visual design.
> We have been unable to identify an existing caching strategy implemented in
> cocoon that will allow us to manage caching for database driven content that
> has an unpredictable update schedule without actually checking in the
> database.  
> Given that, we'd like to begin development of a new caching strategy that
> would allow for an external entity to drive cache management for pipelines
> so configured.  Our initial thought is to use JMS publish/subscribe to
> manage the communication of caching events and we're already prepared to
> deal with this on the external side.  What we're trying to get our heads
> around is the current direction for caching.  It appears from the code in
> CVS that the caching support is being extracted from cocoon and turned into
> an Excalibur component.  
> Can anyone give us an update regarding the status of the caching code and
> let us know where we should be looking as we do our development.  I don't
> want to build this based on the current cocoon classes if they're going to
> be replaced in the near future with a parallel set of Excalibur classes...
> Thanks in advance.
> Steve Sedlmeyer
>, Inc.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message