Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The defaultCache
element is in itself a structure of configuration data for the default cache provider of type cachebox.system.cache.providers.CacheBoxProvider
. This is a reserved cache name and it is MANDATORY to declare and its name or 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. So let's see the configuration keys for our default cache.
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
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:
Key
Type
Required
Default
Description
ObjectDefaultTimeout
numeric
false
60
The default lifespan of an object in minutes
ObjectDefaultLastAccessTimeout
numeric
false
30
The default last access or idle timeout in minutes
UseLastAccessTimeouts
Boolean
false
true
Use or not idle timeouts
ReapFrequency
numeric
false
2
The delay in minutes to produce a cache reap (Not guaranteed)
FreeMemoryPercentageThreshold
numeric
false
0
The numerical percentage threshold of free JVM memory to have available before caching. If the JVM free memory falls below this setting, the cache will run the eviction policies in order to cache new objects. (0=Unlimited)
MaxObjects
numeric
false
200
The maximum number of objects for the cache
EvictionPolicy
string or path
false
LRU
The eviction policy algorithm class to use.
EvictCount
numeric
false
1
The number of objects to evict once an execution of the policy is requested. You can increase this to make your evictions more aggressive
objectStore
string
false
ConcurrentStore
The object store to use for caching objects.
ColdBoxEnabled
Boolean
false
false
A 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 it applies for the default cache ONLY.
The previous CacheBox DSL is a great way to configure CacheBox as it is very portable. However, you can also configure CacheBox by calling methods on the CacheBoxConfig object, which is exactly what we do when we read the CacheBox DSL.
Below are the main methods used for configuring CacheBox which match exactly to the DSL items, so please refer to the DSL items for definitions and settings. Also, for all the methods in this object, check out the API Docs
init([any CFCConfig], [string CFCConfigPath])
The constructor
cache(string name, [string provider=], [struct properties={}])
Add a new cache configuration
defaultCache([numeric objectDefaultTimeout=], [numeric objectDefaultLastAccessTimeout=], [numeric reapFrequency=], [numeric maxObjects=], [numeric freeMemoryPercentageThreshold=], [boolean useLastAccessTimeouts=], [string evictionPolicy=], [numeric evictCount=], [string objectStore=], [boolean coldboxEnabled=])
Add a default cache configuration
listener(string class, [struct properties={}], [string name=])
Add a new listener configuration
logBoxConfig(string config)
Set the logBox Configuration path to use
reset()
Reset the entire configuration
scopeRegistration([boolean enabled='false'], [string scope='application'], [string key='cachebox'])
Use to define cachebox factory scope registration
Let's delve deeper into the rabbit hole and explore how to configure this bad boy. Our preference is the programmatic approach via a simple data CFC that can encapsulate the CacheBox configuration in one single component. However, at the end of the day all configuration approaches will use the CacheBoxConfig
object's methods in some manner.
This is the CFC that you will use to configure CacheBox and its constructor can be called with the following optional arguments which determines your configuration approach:
none
- Means you will be using the CFCs methods for configuration
CFCConfig
- The object reference to the simple data CFC that contains the CacheBox DSL
CFCConfigPath
- The instantiation path of the simple data CFC that contains the CacheBox DSL
No matter what configuration you decide to use, you will always have to instantiate CacheBox with a CacheBoxConfig
object of type: cachebox.system.cache.config.CacheBoxConfig
. However, you have the option of either working with this CFC directly or creating a more portable configuration.
This portable configuration we denote as a simple data CFC that contains the CacheBox configuration data that represents our CacheBox DSL (Domain Specific Language). This DSL is exactly the same if you are using CacheBox standalone or in any ColdBox application, so it definitely has its benefits.
Tip: Please note that you have full access to the running CacheBox's configuration object or even a specific cache's configuration structure. Therefore, you can easily change the configuration settings for a cache or CacheBox dynamically at runtime.
In order to create a simple data CFC, just create a new CFC with one required method on it called configure()
. This is where you will define the caching configuration data structure in a structure called cacheBox
in the variables
scope:
The cacheBox structure can be configured with the following keys:
This is an array of structures that you will use to define cache listeners. This is exactly the same as if you would be declaring ColdBox Interceptors, so order is very important. The order of declaration is the order that they are registered into their specific listening events and also the order in which they fire. The keys to declare for each structure are:
CacheBox has a nifty little feature that enables itself to leech onto a specific scope in memory. It basically can auto-register itself in your environment with no further need for persistence or just to expand its location. By default CacheBox registers itself in application scope with a key of cacheBox, but you have complete control on how the scope registration should work.
Example:
The LogBoxConfig element is used only in standalone mode of operation and tells CacheBox what configuration file to load into LogBox. is an enterprise ColdFusion (CFML) logging library. This way, you have granular control of how CacheBox and its registered caches will be producing logging and debugging data. If you do not specify a location for a custom LogBox configuration file, then CacheBox will instantiate LogBox with its own default configuration file located at:
Example
The default configuration file for CacheBox within ColdBox applications can be found here
This configuration file configures CacheBox with two caches:
default
template
The default
cache can be used for any type of data caching or object persistence. The template
cache is used for event caching and view fragment caching. It is also important to note that the template
cache uses the ConcurrentSoftReferenceStore
for its objects and the default
cache uses the ConcurrentStore
for its objects.
This means that event/view caching is subject to available memory via the JVM, a memory sensitive cache. This is essential as you could have lots of events being cached and you want to be considerate with memory concerns. It is also limited to 300 objects.
Now, this is all nice and dandy, but what if I want to configure CacheBox "MY WAY!!"? Well, don't shout, we are just getting there. There are several ways you can configure CacheBox from within your applications, so chose wisely.
ColdBox allows for a programmatic approach via the ColdBox configuration object: Coldbox.cfc
. So let's look at how the framework loader looks at your configuration for CacheBox configuration details:
Is there a cachebox
DSL variable defined in the configuration structure?
False:
Does a CacheBox.cfc
exist in the application's config
folder?
True : Use that for configuration
False: Configure CacheBox with default framework settings found in /coldbox/system/web/config/CacheBox.cfc
True:
Have you defined a configFile
key in the cacheBox
DSL structure?
True: Then use that value to pass into the configuration object so it can load CacheBox using that configuration CFC
False: The configuration data (CacheBox DSL) is going to be defined inline here so use that structure for configuration
Info The configuration DSL is exactly the same as you have seen in before with the only distinction that you can add a
configFile
key that can point to an external configuration CFC.
That's it folks! You can either write inline CacheBox DSL configuration, use by convention a CacheBox.cfc
data CFC or use a configFile approach for external file loading. Pick your poison!
Key
Type
Required
Default
Description
logBoxConfig
string
false
cachebox.system.cache.config.LogBox
The instantiation or location of a LogBox configuration file. This is only for standalone operation.
scopeRegistration
struct
false
{enabled=true,scope=application,key=cacheBox}
A structure that enables scope registration of the CacheBox factory in either server, cluster, application or session scope.
defaultCache
struct
true
---
The configuration of the default cache which will have an implicit name of default which is a reserved cache name. It also has a default provider of CacheBox which cannot be changed.
caches
struct
true
{}
A structure where you can create more named caches for usage in your CacheBox factory.
listeners
array
false
[]
An array that will hold all the listeners you want to configure at startup time for your CacheBox instance. If you are running CacheBox within a ColdBox application, this item is not necessary as you can register them via the main ColdBox interceptors section.
Key
Type
Required
Default
Description
class
instantiation path
true
---
The instantiation path of the listener object to register
name
string
false
listLast(class,".")
The unique name used for this listener for registration purposes. If no name is provided, then we will use the last part of the instantiation path, which is usually the filename.
properties
struct
false
{}
A structure of name-value pairs of configuration data for the listener declared.
Key
Type
Required
Default
Description
enabled
boolean
false
true
Enable scope registration
scope
string
false
application
The ColdFusion scope to persist on
key
string
false
cachebox
The name of the key in the ColdFusion scope to persist on
The caches element is in itself a structure of configuration data for aggregating named cache providers of ANY type. The key is the unique name of the cache to aggregate under this CacheBox instance. The value should be a structure with the following keys:
Example:
Key
Type
Required
Default
Description
provider
string
true
---
The instantiation path of the cache that must implement our ICacheProvider
interface.
properties
struct
false
{}
A structure of name-value pairs of configuration data for the cache to declare.