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"
logger="sitemap.generator.userGen"
label="content,data"
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"/>
</map:match>
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="http://apache.org/cocoon/include/1.0";>
<cinclude:include src="cocoon:/roles"/>
<cinclude:include src="cocoon:/user"/>
</page>
Here is the code which invalidates the "user" pipeline:
<code>
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
userPCKey.addKey(ccKey);
// remove generator cache
store.remove(userPCKey);
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
wanted.
// CachedEventObject cachedObject = (CachedEventObject)store.get(pcKey);
transPCKey.addKey(ccKey);
transPCKey.addKey(userPCKey);
/**
* 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.
*/
store.remove(transPCKey);
</code>
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
http://localhost:8080/user
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.
Regs,
Nick
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
> Crosswalk.com, Inc.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
