Geoff,
- No cache element is needed in cocoon.xconf because it's defined in cocoon.roles (and if you just removed the event-cache by deleting the xconf entry you probably didn't really remove it) - The cache role is a wrapper around transient-store and persistent-store which come predifined in cocoon.xconf
Okay. All I was doing was switching from transient to persistent, but your explanation below tells me I don't need to do that.These components work together like this:
Cache wraps transient-store which uses persistent-store (if and only if *<parameter name="use-persistent-cache" value="true"/> is set on transient-store in cocoon.xconf which it is by default)
All new items go into the transient-store, and if configured, older items are moved into persistent-store when they are bumped off the bottom of the stack, or on container shutdown. All this happens by default out of the box and is working correctly (unless you delete/fail to reuse the cache-dir as Jetty does) for the servlet mode.
As far as I can see, I reuse the cache-dir. Or at least, there's a file in the cache-dir that gets updated, and I use the same cache-dir each time.
...
Anyway, I've done some more research, including downloading the source for Avalon (for the first time!) and stepped through the code for the Store.
...
Vadim's already answered you on that but another point is that I'm pretty sure there's nothing wrong with the Store(s) or Cache because I don't see this happening in the webapp. You could prove this to yourself by configuring the max-objects param for transient-store in cocoon.xconf to a very small number (like 5) and then watching items go into the persistent storage by using the webapp some. You can then use the sample to clear the MRU store and you'll see that you can still get cached responses out of the persistent-store.
Let me know how that turns out.
Geoff
