When we've had the need to cache a query, we just throw the result (as a DOM object) into the sesssion. I'm including the sample pipeline. I'll typicailly aggregate the results of this with something else (usually a dynamic query) and I'm all set. When I want to clear the cache, the session attribute can be cleared.
(note, the getUserIdAction is something we wrote to grab the logged in user out of the session. We use container based authentication, but stash an object in the session for use in the sitemap).

We also ended up writing an action to invalidate a sesion object (used to clear the cache).

<map:pipeline internal-only="true">
<map:match pattern="assoc-list">
<map:act type="getUserIdAction">
<map:select type="sessionAttributeExists">
<map:parameter name="attribute-name" value="assoc-cache"/>
<map:when test="true">
<map:generate type="session-attr">
<map:parameter name="attr-name" value="assoc-cache"/>

<map:serialize type="xml"/>
<map:generate src="xml/assoc_query.xml"/>
<map:transform type="sql">
<map:parameter name="use-connection" value="mbrdb"/>
<map:parameter name="userid" value="{userid}"/>
<map:transform type="writeDOMsession">
<map:parameter name="dom-name" value="assoc-cache"/>
<map:parameter name="dom-root-element" value="page"/>

                       <map:serialize type="xml"/>


Christian Kurz wrote:

I just skimmed through the mailing list to find ideas of how to cache a
pipeline starting with a request generator and later on passing data
through the SQLTransformer.

Did you or anybody else follow up on this idea?

NB: Caching of the request generator would probably also need to cache request parameters passed not part as part of the URL. As usually only some request parameters are used in the pipeline, the sitemap element might list the request parameters to consider when generating cache key:

<map:generator type="request">
   <map:parameter name="request-data-used" value="input1">
   <map:parameter name="request-data-used" value="input2">


A couple of things I'd like to do with Cocoon caching; let me know if
is crazy.

1. Add caching to the request generator.  Many of my pipelines are
transformations based upon the request, and since requestGenerator
does not support caching, it means those transformations are always
(and often there is some sql at the end of the pipe which is really
I'd like to hash (or MD5?) the request string and use that as the cache
so that if I get the same one the pipeline knows it can skip over

2. Add caching to the SqlTransformer.  I know this sounds weird, but
hear me
out.  Our database is modified infrequently, so usually returns the same
data.  There is a datestamp in a special table which indicates when the
time the database was updated.  The SQL Transformer would remember the
of the last query.  I would have a new parameter to the sql transformer
indicate when the data is dirty.

       <map:transform type="sql">
         <map:parameter name="last-update-time"

LastUpdateTime looks like:

<Date>20021005144321</Date> (Or whatever the xml date format is, I

SQLGenerator would resolve cocoon:/lastUpdateTime.xml.

I would then have a pipeline for lastUpdateTime.xml which would build it
querying my special table (but if you wanted, you could use some other
mechanism to build it).

SQLGenerator would compare the two dates and re-run the sql if it needed

How does this sound?


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to