As a follow up to my first first CF9 caching post, today I want to share a simple example that addresses the issue of using the session scope and caching.
As I mentioned in the last post, the caching API in ColdFusion 9 is application based. That means the cache with ID "foo" will be the same for every visitor to your application. How can we get around this? Well don't forget that every session has a unique identifier in the URLTOKEN value. This is really meant to be used for supporting cookie-less browsers, but it works well as a simple unique identifier. Here is a pretty trivial example showing this in action.
<cfset myUniqueId = session.urltoken & "totalorders">
<cfset myOrders = cacheGet(myUniqueId)>
<cfif isNull(myOrders)>
<!--- fake slow process again --->
<cfset sleep(1000)>
<cfset myOrders = randRange(1,100) & " " & createUUID() & " " & randRange(1,100)>
<cfset cachePut(myUniqueId, myOrders)>
</cfif>
<cfoutput>Session specific cache value: #myOrders#</cfoutput>
I create a key based on both the urltoken and another value that represents the data I want to cache (totalorders). I then grab this from the cache. Rob had made the comment in my last post that I should simply grab the value and see if it existed. I had avoided that at first because I forgot about the addition of isNull, but as you can see, this makes the code somewhat simpler now.
The actual code inside the CFIF is not important - it just fakes a slow process. But note that when I store the value I use the ID based on my session.urltoken and the string, "totalorders".
You can view this demo here: http://cf9.coldfusionjedi.com/caching/test4.cfm
Remember in the last entry I built a generic 'dumper' for all the caches in the current application. If you view that here, you should see it slowly grow as more people visit the blog entry.
So you may ask - why bother? Session data already persists and will be cleaned up when the session expires. That's definitely true. However, if you want more fine control over the duration of the data (something less than normal session timeout) or if you want to introspect all of the cached data across sessions, then this would be a nice option. You can also use the idleTime support. For sessions from robots, which typically don't persist past the first hit, avoiding the "pure" session scope for them means the data you store can expire earlier than a normal session expiration if the idleTime is set well. Just thinking out loud here of course!