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

12 Days of BoxLang - Day 4: TestBox

12 Days of BoxLang - Day 4: TestBox

Today we’re celebrating one of the most exciting new additions to the BoxLang ecosystem:

the TestBox BoxLang CLI Runner — a fast, native way to run your TestBox tests directly through the BoxLang Runtime. ⚡

No server required. No CommandBox needed. Just pure, ultra-fast BoxLang-powered testing from the command lineon Windows, Mac, and Linux.

If you’re building modern applications with BoxLang — web apps, CLIs, serverless functions, Android apps, or OS-level utilities — this new feature gives you a unified, flexible testing workflow you can run anywhere.

Victor Campos
Victor Campos
December 13, 2025
12 days of BoxLang - Day 3: SocketBox!

12 days of BoxLang - Day 3: SocketBox!

As BoxLang continues evolving into a modern, high-performance, JVM-based runtime, real-time communication becomes essential for the applications we all want to build: dashboards, collaboration tools, notifications, live feeds, multiplayer features, and more.

That’s where SocketBox steps in — the WebSocket upgrade listener built to work seamlessly with CommandBox and the BoxLang MiniServer. ⚡

Today, for Day 3, we’re highlighting how SocketBox supercharges BoxLang development by giving you fast, flexible, and framework-agnostic WebSocket capabilities.

Maria Jose Herrera
Maria Jose Herrera
December 12, 2025
12 Days of BoxLang - Day 2: CommandBox

12 Days of BoxLang - Day 2: CommandBox

BoxLang + CommandBox: The Enterprise Engine Behind Your Deployments

For Day 2 of our 12 Days of Christmas series, we’re diving into one of the most powerful parts of the BoxLang ecosystem: CommandBox the defacto enterprise servlet deployment platform for BoxLang.

If BoxLang is the language powering your applications, CommandBox is the engine room behind it all. ⚙️

Victor Campos
Victor Campos
December 11, 2025