Blog

Brad Wood

February 28, 2013

Spread the word


Share your thoughts

 

Every ColdBox install comes with an instance of the CacheBox cache aggregator ready to go.  There are two caches that have to be defined: default, and template.  The former is the default provider used if you don't specify another one.  The latter provider is used internally for cached events and views.  What's cool about CacheBox as a cache aggregator is that you can configure as many named providers as you like to report and tune separate areas of your application.
 
Adding an additional named cache is easy and has virtually no overhead since most providers don't use any memory until you begin populating them with data.  Let's start by taking a look at your cache debug monitor:
http://www.mySite.com?debugMode=1&debugpanel=cache
 
 
 
Now, first off you might be wondering how the default and template cache are defined since you might not have any CacheBox-specific configuration in your app.  Don't worry-- if you don't supply any CacheBox configuration, it defaults to the settings found in /coldbox/system/web/config/CacheBox.cfc.  Once you do begin including config for CacheBox, you'll need to include the default and template caches.  
 
Where you store your CacheBox config is completely configurable, but the two most common places is a "cachebox" struct in your main /config/ColdBox.cfc file, or in a separate file /config/CacheBox.cfc that works just like the main config.  My preference is the separate CacheBox.cfc file for organization.  You can get started by simply making a copy of the default CacheBox.cfc in your app's config directory. 
 
To add additional caches, you just need to add more nested structs to the "cachebox.caches" struct like so (I omitted all the default and template details for brevity):
 
cacheBox = {
    defaultCache = {
    ...
    },
    // Register all the custom named caches you like here
    caches = {
        template = {
        ...
        },
        // My new named cache!
        myCache = {
            provider = "coldbox.system.cache.providers.CacheBoxColdBoxProvider",
            properties = {
                evictionPolicy = "LRU",
                maxObjects = 300,
                objectStore = "ConcurrentSoftReferenceStore"
            }
        }
    }
};
 
Now, reinit your application and refresh the cache debug screen.  Your new cache name should show up in the drop down for you to view the stats and contents of it.
 
Using your new cache is also easy.  In a handler for example, the following code is all that is needed:
var myCache = CacheBox.getCache("myCache");
 
If you want to wire your new cache into a model, the following DSL will also work:
component {
    property name='myCache' inject='cachebox:myCache';
}
 
 
P.S. Don't forget to add a debugPassword setting into your app to ensure that you are the only one who can fool around with your CacheBox debug panel.  The URL only changes slightly when you have password:
http://www.mySite.com?debugMode=1&debugpass=myPass&debugpanel=cache

 

Add Your Comment

Recent Entries

TestBox 7 : Real-Time Streaming, a Browser IDE, and a Major Leap for BoxLang

TestBox 7 : Real-Time Streaming, a Browser IDE, and a Major Leap for BoxLang

TestBox 7.x series continues our mission to be the best testing framework for BoxLang and CFML. This release is focused heavily on BoxLang CLI runner enhancements, real-time streaming test execution via SSE, a powerful dry run capability, the brand-new TestBox RUN web IDE, and significant quality-of-life improvements for developers working in both BoxLang and CFML environments.

Luis Majano
Luis Majano
March 17, 2026
From Legacy Risk to Modern Agility: A Phased Modernization Roadmap for CFML Teams

From Legacy Risk to Modern Agility: A Phased Modernization Roadmap for CFML Teams

Many organizations running CFML applications today face the same challenge.

Their systems still work.

They support core business processes.

They generate revenue.

But at the same time, those platforms are increasingly exposed to risk.

Unsupported runtimes, operational fragility, security exposure, and difficulty integrating with modern systems are becoming more common in environments still running older versions of Adobe ColdFusion or Lucee.

The quest...

Cristobal Escobar
Cristobal Escobar
March 16, 2026
Introducing the BoxLang Spring Boot Starter: Dynamic JVM Templating for Spring

Introducing the BoxLang Spring Boot Starter: Dynamic JVM Templating for Spring

Spring Boot developers know the pain of evaluating view technologies. Thymeleaf is great — until you need more expressiveness. FreeMarker is powerful — until the syntax fights you. What if you could write templates in a dynamic JVM language that gives you the full power of the platform, feels natural, and requires zero setup to integrate?

Meet the BoxLang Spring Boot Starter.

Luis Majano
Luis Majano
March 13, 2026