Demonstrating Event-Aware Caching

This page is a sample for event aware caching. We subclassed the JXTG template generate for this sample. If you don't already understand at least the basics of caching in Cocoon, you should probably start there, not here. Read the text below, and the sitemap and source for more details.

I pause for 2 seconds during generation, so that you can tell if I'm being served from the cache or not.
What you see here was generated on Wed Oct 18 05:01:09 UTC 2017.

I'm cached for each unique value of request parameter 'pageKey'. Other parameters do not matter.
Here the value is: one.
If this is not the same as the 'pageKey' parameter in the page URL, we have a problem.

Unlike other cacheable pages in Cocoon, I can be un-cached by events external to Cocoon - for instance, when a database table or row is updated.
My cache entry will be invalidated (actually, removed) when an event named one occurs. This can be manually simulated by clicking one of the "uncache" links below.

Test links:

Note: the random numbers you see included in the url after an uncache link serve two purposes in the example, making it easier to see the effect of the cache invalidation. They prevent browser caching and they demonstrate that only our designated key matters in the retrieval from cache.

This event based cache system consists essentially of three parts:

Note that though this example extends the jxtg in combination with actions or flow, any pipeline component can be made to use EventValidity, and any code with access to the ServiceManager can translate real-world events to Events and notify the Cache of them.