custom component cache keys

Lee

Hi
We need to cache components based on some user attributes which are not segments and not passed into a component (so does not impact the component checksum). What is the best approach to caching these components ?

I've got 3 possible solutions but I'm not happy with the first and I don't know how to implment the other two :-)

Option 1 - add each attribute as a site segment and execute each segment on every page. (segments are used in the component cache key) this has the draw back of performance (executing the segments for each page render) which we have over came a little with custom segment execution code. however it also has the draw back of creating an un-wanted site map for our users to get confused by. (is there a way of having a site segment without a site map ?)

option 2 - create a custom implementation of the component cache pool which allows custom cache keys to be used. or maybe we don't have to do this and we can config existing cache pool ?. This is the solution i'm most interested in as it seems the correct approach in our situation

option 3 - hack the user attributes into the component defintion and pass in the values at run time so that the component checksum uses these values to be calculated. The checksum is used as part of the cache key. I suppose a bit like ls_page_name being available to use in the component defintion. Again what is the best way to expose the user attributes in this way ?

Open to other options

Cheers Lee C

Rick Poulin

Option B is the only real option. A is not really a solution at all, and C is going to be very unsupported.

In my experience, Option B is almost always required anyway as soon as you write any bit of Java. LiveSite only provides capabilities to cache the very final rendered HTML, and very often what you want to cache is just the data.

e.g. consider the case where your C-clamp components are cached for 60 mins. The keys are the pages, so they are likely cached at different times for different pages. Make a major change to your sitemap, and it'll start popping up on different pages at different times, as the cache for those individual pages expires > terrible user experience. What you want is to cache the sitemap file, and set all your C-clamp components to 'do not cache'. This way, you avoid the I/O which is the most expensive part of the operation, while maintaining consistency across all pages.

For basic cases, this is easy to write custom (disclaimer: I just typed this out in devnet so take with a grain of salt):
[PHP]
public class MyExternal {
private static long lastRead = 0l;
private static Document someObj = null;
private static final int DELAY = 5000; // 5 secs

public Document getThatData(RequestContext context) {
Document out = null;
if (lastRead == 0l || lastRead + DELAY < Calendar.getInstance().getTimeInMillis()) {
reloadThatData();
}
synchronized (lastRead) {
// Clone because 1) thread safety and 2) LiveSite destroys Documents it renders
out = (Document) someObj.clone();
}
return out;
}

private void reloadThatData() {
Document newData = null;
// TODO: create newData from wherever
synchronized (lastRead) {
someObj = newData;
lastRead = Calendar.getInstance().getTimeInMillis();
}
}
}
[/PHP]
Extending this concept to use a Map of objects with whatever keys suit your purpose should be fairly straightforward.

The advantage of using a framework like JCS is if you want something that can easily be configured, tweaked, and cleared from a screen somewhere. The underlying logic is the same. My personal preference has always been to write the above as an interface, such that if you want to substitute a JCS later, you can.