Caching Enhancements in ColdFusion 9

July 17, 2009 · 20 Comment s

One of the less mentioned aspects of ColdFusion 9 is the enhanced caching that was added by including ehcache under the covers.

This opens a number of possibilities including fragment caching:

<cfcache action="serverCache" timespan="1">
   <cfoutput>
      <p>The time was #DateFormat(Now(), "mmmm d, yyyy")# 
      #TimeFormat(Now(), "hh:mm:ss tt")#</p>
   </cfoutput>
</cfcache>

<cfoutput>
   <p>The time is #DateFormat(Now(), "mmmm d, yyyy")# 
   #TimeFormat(Now(), "hh:mm:ss tt")#</p>
</cfoutput>

In this code, the first <cfoutput> will always show the time from the first time it was called. The second <cfoutput> will show the time from the actual time the code is called. The 1 for timespan means that it will cache that value for a day.

But, we can also do dependent cached items, where the value of one of the contained variables has an impact on whether or not the cached item needs to be refreshed.

<cfset minutesVariable = minute(now()) />

<cfcache action="serverCache" dependson="minutesVariable">
   <cfoutput>
      <p>The minutes is #minutesVariable#</p>
      
      <p>The time was #DateFormat(Now(), "mmmm d, yyyy")# 
      #TimeFormat(Now(), "hh:mm:ss tt")#</p>
   </cfoutput>
</cfcache>

In the above code, assume that it is called at 12:03. For the next minute minutesVariable is going to equal 3. For each call where minutesVariable equals 3 the cache is used. However when the time rolls over to 12:04, minutesVariable will equal 4. This will trigger a refreshing of the cache with the new content being cached for the next minute.

In addition to fragments, I can also cache objects (but for easy of understanding, variables) See this code:

<cfcache action="get" name="test" id="testQuery">

<cfif not structkeyExists(variables, "test")>
   <cfquery name="test" datasource="cfartgallery">
      SELECT    *
      FROM    Artists   
   </cfquery>
   <cfcache action="put" value="#test#" id="testQuery">
</cfif>
<cfdump var="#test#">

I try and retrieve the query that I've given an id of "testQuery" from cache, if it's not there, I call the query and cache it.

So those are three fairly straight forward examples of the new caching, but you can do much more with it, including invalidating objects, analyzing cache usage, and more.

Tags: ColdFusion · Centaur

20 response s so far ↓

1 Raymond Camden // Jul 17, 2009 at 1:40 PM

A small point on dependsOn, and to be clear, I love this new feature. I begged for better caching. So take this as a minor nit.

dependsOn is really more of a key. A unique key that determines if the cache has changed.

To me, when I first read dependsOn, I thought it was creating some kind of 'live connection'. So to use your example, I wouldn't have to reload the page. CF would "know" when the value changes and clear the cache for me.

Obviously that isn't the case. If you never visit this page again, it will persist as long as the application scope does. I also tended to think of dependsOn as a CACHE dependency. Ie, cache item C is bound to cache item P. If cache item P changes, or times out, it should kill the C cache. This is how I built ScopeCache and it lets you create a 'tree' of cache objects that you can easily clear at once.
2 Terrence Ryan // Jul 17, 2009 at 1:53 PM

That's a great point, Ray.

I would point out though that the key metaphor goes out the window when you add in that dependsOn can take a list of variable names. When any of those variables change the fragment is rerun and cached.

But the live connection could through people for a loop. But on the other hand, if a cache fragment's dependency variables falls in the woods, does it change the cache? If you aren't displaying the fragment does it matter that the dependency variable has changed?
3 Raymond Camden // Jul 17, 2009 at 2:00 PM

Even with multiple variables, it is still just a key really. I mean shoot, why did they use the name of a variable anyway? CF is just going to evaluate it. ;) I'm being picky now - but dependsOn really kinda bugs me. I think it implies a direct relationship when there really isn't one.

But - I'll live with it. ;)
4 Jeremy Prevost // Jul 17, 2009 at 2:13 PM

Yay for better caching!
5 Henry Ho // Jul 17, 2009 at 5:03 PM

I don't get it. What's the diff between using cfcache to cache the object vs putting the object in Application scope?
6 Terrence Ryan // Jul 17, 2009 at 5:06 PM

@Henry The example I put here is pretty simple. The cache tag allows you to add parameters that add a timeout to the cache, either absolute, or from last time hit, additionally you can programatically invalidate cached items.

In short, you can do a lot more then just store it, which is the advantage over a shared scope.
7 Chris S // Jul 18, 2009 at 10:17 PM

Thanks for the post. This is a huge feature and perhaps unappreciated.

The end result is the ability to scale and generate pages faster with less servers. And with the move to the cloud, DB hits generally becomes a much more expensive operation. Being able to persist data into the cache with sub-millisecond retrieval is great.

All that can be cached should be cached. Both static page fragments and user customized fragments. Facebook has a limited number of PHP application servers but a lot of memcached instances. The same principles apply to CF/ehcache.

Will the cache survive and be reference-able across CF restarts? Looks like no, but I hope I am wrong. Can Ehcache still manage it's own distributed cache? What version of Ehcache is the beta using? What version do you expect the release to use? Will it be possible to update Ehcache independent of CF?

As a general point it would be great to know if any of the baked in components will be able to be updated independently (ExtJS, Hibernate, Ehcache, Solr) Waiting 2 years (between CF releases) for an update of sub components is too long. Let us manage be able to drop in updates or Adobe needs to do quarterly dot releases. Move to a subscription licensing model. CF has the slowest release cycle. This may not matter for corporate users, but in the web world 24 months is an eternity.
8 Raymond Camden // Jul 18, 2009 at 11:49 PM

I'd argue that if you are experienced enough to know that the baked in version of X doesn't support your needs, then you can probably handle the upgrade yourself. Folks can easily get newer ExtJS. Folks use Solr _now_. Folks use Hibernate now even. So nothing is to stop you from switching to a non-baked in version if you need to.
9 Henry Ho // Jul 19, 2009 at 1:06 AM

The baked-in Hibernate cannot be upgraded, Adobe said during one of the CF9 presentations. The reason being Adobe had to do some customization on top of Hibernate.
10 Raymond Camden // Jul 19, 2009 at 10:11 AM

You misread me Henry. What I said was, if you wanted something new in Hibernate X (X being some new version), then you CAN install it yourself and use it yourself via CF. It would NOT be the same tags/functions as the built in stuff. Ditto for using new Ext, etc.

But you absolutely, 100%, can do it. My last work at Broadchoice involved ColdFusion and Hibernate and it worked great.
11 Chris S // Jul 19, 2009 at 9:08 PM

@Ray, you are correct. But then the value of Adobe's ColdFusion diminishes with each day.

If Adobe wants thousands of dollars in a space dominated by free open source, then there has to be value add. That would keeping the main components of the release current and issue free. If have to start writing my own connectors to stuff I paid for and that is supposed to be built in, then why bother with Adobe's product at all? That said I think the approach with CF9 is fantastic. I think the choosing Hibernate, ehcache, solr is great. Put me on a maintenance plan and update. Do the heavy lifting for me.
12 Raymond Camden // Jul 19, 2009 at 9:49 PM

I strongly disagree with you. I've used Hibernate before, but not to the point where I'd care about a minor update. I will be happy with the 'baked in' version for quite some time, and I'd be willing to bet a majority of Adobe's customers are in the same boat. And I'd apply that to all of these things that are baked in (Lucene, Ext, etc).

There is -great- value add in not having to install/setup/configure anything outside of CF.
13 Chris S // Jul 19, 2009 at 10:21 PM

@Ray, fair enough and interesting. Perhaps it is a matter of perspective? Living with a site(s) for years vs project-based consulting?

CFhour() covers this exact topic with Adam Lehman.
http://www.cfhour.com/detail.cfm?entry=8AAE09B7-B7E4-8D4E-57FE66221A620990

Listen to minutes 20-25 as they discus the non-upgradability of ExtJS in CF8 and how that is a point of pain. At minute 23, Adam hits this point directly. GOOD NEWS! Adam said CF will have hot fixes that will pick up Ext releases...with in weeks! So I just need to know does this strategy extend to the other baked-in components? So if v1.6.1 of ehcache is released and there is another 50 times performance gain, will that also be hot fixed released within weeks? It would be great if Adobe were more vocal on this point. (for those of us that are interested :) )
14 Raymond Camden // Jul 19, 2009 at 10:25 PM

Yes, it does sound good, I'm just not convinced how critical it is. I'd think most people who know that baked in version of X is old is probably not the market for the baked in X. Know what I mean? :)
15 Chris S // Jul 19, 2009 at 11:01 PM

Removed at request of commenter.
16 Chris S // Jul 19, 2009 at 11:32 PM

I can't edit comments so let me repost as I wasn't clear. My point is everyone wins with updates. The hot fix approach is a smart way to let users opt in as wanted.

Updates are valuable to those that don't know about baked-in components. They can get additional performance benefits with little to no effort. Example Adobe hotfix releasing an updated version of ehcache. Who doesn't want faster loading pages?

Then for those that are in the know, there is huge value add in Adobe doing the heavily lifting of doing the integration testing. Once the hotfix is out, I just have to do a quick test with my app to make sure all is good. If I was working with a stand alone version, the workload could be much greater if some of the underlying APIs had changed.

I think the benefits of frequent Ext updates are obvious to even a enthusiast developer. Beside improved features, there could be underlying speed and compatibility fixes. Who wouldn't want that for the few minutes of time to instal a hot fix using the new admin tool?

To me this is the benefit of going with a commercial product. The open source web app development platforms don't stand still. Look at Railo, PHP or RoR. While not every user of CF cares about every update, I can't agree that CF should stagnate for 24 months at a time.
17 Raymond Camden // Jul 20, 2009 at 5:38 AM

Oh, I didn't mean to imply only sophisticated users would want them - more that the audience/group of people who would need/want them would be the minority, and those who did want/need them could probably handle the update themselves.

I'm not _opposed_ to hot fixes for the related stuff of course, but you use performance as your example. What if the new version of ehcache has a new feature as well? Adobe can't just roll out a new tag (or even attribute) w/o serious testing and documenting. I think you minimize the effort required for a hot fix. SHoot, even if it's just ExtJS files, I'm sure there is at least a good week or two of testing apps to ensure stuff doesn't break.

I guess my point is - I'm definitely not opposed to updates for this stuff, I'm just not sure how much _worth_ there is in Adobe spending a lot of time trying to keep up with all of em, as opposed to continued work on CF10, or, CF9.0.1 (since there is almost always a 'point' update post release).
18 Jeremy Prevost // Jul 21, 2009 at 10:01 AM

I think at least part of the 'worth' to Adobe is that some third party updates might sneak in minor security fixes that go unnoticed and leave users unnecessarily exposed to risk (think FCKeditor).

Knowing that Adobe would be patching as a matter of course, rather than everyone sitting back and hoping they'll patch the security problem and that it won't break lots of other stuff, would make me more comfortable.

Another big bonus for Adobe would be that every major version of ColdFusion would have less to worry about with these third party updates and could focus on new value added features (or core performance).
19 Catty // Jul 24, 2009 at 3:03 PM

The comments in this thread remind me of this: http://tr.im/tTWq
20 Financial Planning Raleigh // Nov 19, 2009 at 12:03 AM

Thanks for such a nice post.

Regards

Blog