Blog

Brad Wood

May 23, 2013

Spread the word


Share your thoughts

An important piece of a well-performing application that can scale under load is caching.  This can (and should) be implemented at multiple levels.  CacheBox is an enterprise cache API and aggregator that can be used stand-alone and comes bundled with the ColdBox framework.  ColdBox has some nice hooks to allow you to utilize CacheBox in several ways with very little work and Event Caching is one of those ways.

Event Caching gives you the ability to cache the result of any event in your application so that subsequent requests will bypass all the processing in your handlers, views, and layouts, and immediately return the cached response.  This is great for APIs or sites with data that is accessed more than it is modified, or if the data being displayed doesn't need to be up-to-the-second fresh.  

Here's some things to consider about Event Caching:

  • It is easily activated by toggling a setting and then adding cache=true to the actions you want cached in your handler.
  • A different item will be created in the cache for each unique permutation of values in the request collection.
  • You can control how long the event is cached in minutes with cacheTimeout=30.
  • All handler processing is skipped, so you won't want to cache events that need to save to the database or modify the state of the application
  • PreProcess/PostProcess interceptors and requestStart/requestEnd events will still run even if the event is cached

Let's look at how easy Event Caching is to start using.  First, you'll need to enable Event Caching in your config like so:

coldbox.eventCaching = true;

Next, set cache=true in the method declaration of the action you want to cache in your handler.  cacheTimeout is an optional parameter to control how long the event is cached.  cacheLastAccessTimeout is an optional parameter that will cause the entry to be cleared from the cache sooner if it isn't being used.

function showEntry(event,rc,prc) cache="true" cacheTimeout="30" cacheLastAccessTimeout="15"{
    //get Entry
    prc.entry = getEntryService().getEntry(event.getValue('entryID',0));
        
    //set view
    event.setView('blog/showEntry');
}

Since entryID is stored in the request collection, there will be a different cached response for every entryID that the site is access with.  Keep in mind the maximum number of items which can be stored in your "template" cache.  Furthermore, if your site employs things such as localization, you might want to ensure that a version of the event gets cached for each language.  Setting getFWLocale() into the rc in an onRequestCapture interceptor is an excellent way to ensure caching takes the user's language into account.

More info here: http://wiki.coldbox.org/wiki/EventHandlers.cfm#Event_Caching

P.S. What do you do if your data changes, but the event is still cached?  You can programatically expire events from the cache by grabbing the "template" cache and using the clearEvent(), clearEventMulti(), or clearAllEvents() convenience methods.

cachebox.getCache("template").clearAllEvents();

Add Your Comment

Recent Entries

One Language, Every Runtime: BoxLang Expands Beyond the Server

One Language, Every Runtime: BoxLang Expands Beyond the Server

Discover how BoxLang’s multi-runtime architecture helps developers build beyond the server with support for serverless functions, desktop applications, CI/CD workflows, Java integrations, containers, runtime management, and more.

Maria Jose Herrera
Maria Jose Herrera
June 04, 2026
MatchBox and WebAssembly: Running BoxLang in the Browser and at the Edge

MatchBox and WebAssembly: Running BoxLang in the Browser and at the Edge

The MatchBox open beta is live at https://boxlang.ortusbooks.com/boxlang-framework/matchbox, and it brings something genuinely new to the BoxLang ecosystem: a path into WebAssembly.

That means BoxLang code can now move into browser applications, static-site deployments, edge runtimes, and WASI-style containers - without requiring a JVM. The feature is still beta, but the core direction is already useful: write BoxLang, compile it with MatchBox, and ship the generated WASM artifact to wherever a small portable runtime makes sense.

Jacob Beers
Jacob Beers
June 04, 2026
BoxLang 1.14.0 : BoxSet is Here: BoxLang's New First-Class Set Type

BoxLang 1.14.0 : BoxSet is Here: BoxLang's New First-Class Set Type

BoxLang 1.14.0 ships something that JVM developers have wanted for a long time: a true first-class Set type baked directly into the language. Not a wrapper you reach for manually, not a createObject( "java", "java.util.HashSet" ) incantation you paste from a Stack Overflow answer years ago. A real BoxSet with literal syntax, operator overloads, a full functional pipeline, change listeners, JSON serialization, and deep Java interop.

Luis Majano
Luis Majano
June 03, 2026