CacheBox DSL
As we have seen, the CacheBox DSL can be used in different contexts:
Portable CFC with a
configure()
method in acachebox
variableColdBox config inside the
configure()
method in acachebox
variableA struct literal is sent into the constructor of CacheBox
No matter how you dice it, it's the same CacheBox Config DSL:
Base Config
The cacheBox
structure can be configured with the following keys:
LogBoxConfig
The LogBoxConfig element is used only in a standalone mode of operation and tells CacheBox what configuration file to load into LogBox.
LogBox is an enterprise ColdFusion (CFML) logging library
By default, CacheBox will instantiate LogBox with its default configuration file located at: cachebox.system.cache.config.LogBox.cfc
which logs to the console.
Scope Registration
This configuration allows CacheBox to be placed automatically upon construction in your specified scope. By default, CacheBox registers itself in application
scope with a key of cachebox
DefaultCache
Every CacheBox instance has a default
cache that can be configured as you like. Above you can see the default configuration for the cache.
This is a reserved cache name, and it is MANDATORY to declare, and its name or provider type cannot be changed.
However, if you are using CacheBox within a ColdBox application, the provider will switch itself to cachebox.system.cache.providers.CacheBoxColdBoxProvider
by using the coldboxEnabled
key.
objectDefaultTimeout
: numeric
objectDefaultTimeout
: numericThe default lifespan of an object is in minutes. This is how long an object lives within the cache. If this value is 0
then all objects will be eternal, meaning they will live forever.
objectDefaultLastAccessTimeout
: numeric
objectDefaultLastAccessTimeout
: numericThe default last access or idle timeout in minutes. If an object has not been accessed within this time limit since the last access, then it will be marked for purging.
useLastAccessTimeouts
: boolean
useLastAccessTimeouts
: booleanBy default, the last access timeout is enabled. You can disable this purging feature if you desire.
resetTimeoutOnAccess
: boolean
resetTimeoutOnAccess
: booleanIf true, then when cached objects are retrieved their timeout will be reset to its original value thus elongating the survival strategy of the items. Much how session storages work on JEE. The default is false, meaning the timeout will NOT be reset on each access.
reapFrequency
: numeric
reapFrequency
: numericEvery CacheBox provider has its own executor service with a reaping task executing under this frequency. This is how often the cache is inspected to purge old/invalid keys.
freeMemoryPercentageThreshold
: numeric
freeMemoryPercentageThreshold
: numericThe numerical percentage threshold of free JVM memory to be available before caching. If the JVM free memory falls below this setting, the cache will run the eviction policies to cache new objects. If you set this value to be 0
, there will be no free memory checks.
evictionPolicy
: string
evictionPolicy
: stringThe eviction policy algorithm to use. The available algorithms are:
LFU
LRU - Default
LIFO
FIFO
Custom
evictCount
: numeric
evictCount
: numericThe number of objects to evict once an execution of the policy is requested. You can increase this to make your evictions more aggressive. By default, one object is purged from the cache. However, you can increase it to purge more than one as needed.
maxObjects
: numeric
maxObjects
: numericThe maximum number of objects the cache can have, give or take, expired objects. Once a limit is reached, the cache will start purging objects using the eviction policy and counts. The default is 300.
coldboxEnabled
: boolean
coldboxEnabled
: booleanA flag that switches on/off the usage of either a plain vanilla CacheBox provider or a ColdBox enhanced provider. This must be true when used within a ColdBox application and applies to the default cache ONLY. For standalone mode, ignore this or always set it to false.
objectStore
: string
objectStore
: stringEach CacheBox provider can have a strategy of where to store the objects. These are called object stores. The value here is the name of the store. By default, we use the ConcurrentSoftReferenceStore
.
Eviction Policies
,LFU (Least Frequently Used)
LRU (Least Recently Used)
FIFO (First In First Out)
Custom: You can also build your own and pass the instantiation path in this setting
Object Stores
ConcurrentStore - Uses concurrent hashmaps for increased performance
ConcurrentSoftReferenceStore - Concurrent hashmaps plus java soft references for JVM memory sensitivity
DiskStore - Uses a physical disk location for caching (Uses java serialization for complex objects)
JDBCStore - Uses a JDBC datasource for caching (Uses java serialization for complex objects)
Custom : You can also build your own and pass the instantiation path in this setting.
Caution : Please note that each object store could have more configuration properties that you will need to add to the configuration structure. To find out about these extra configuration properties, please see the Object Store's section.
Example:
Caches
The caches
element is a configuration data structure for aggregating named cache providers of ANY type. The key is the unique name of the cache to aggregate under this CacheBox instance. Each provider has unique configuration properties, so explore them as well.
Listeners
CacheBox has an event-driven model where you can listen to cache operations and cache factory operations. You do so with listener CFCs that you register in your config, mostly for standalone operation. In ColdBox, all interceptors have access to all events.
Caution: Please note that the order of declaration is the same as the order of execution, so it matters, just like ColdBox Interceptors. Using CacheBox within a ColdBox application, you can also register listeners as interceptors in your ColdBox configuration file.
Last updated