The functionality for caching arbitrary objects is provided by at least two modules.
magnolia-cache-corewhich defines the cache API.
- A second module which implements the API. Magnolia provides two implementations based on established third-party libraries for the low-level functions.
Things to note about arbitrary object caching
Speed up services
The main reason to cache objects is to serve data faster and to save resources (cpu, memory, network load, etc.). For instance, use object caching when there is heavy request on a Magnolia "service" which must provide data from a remote source.
Assure data validity
When delivering cached data you will probably need a mechanism to ensure cached data is valid and not outdated! How to handle this depends on the use case.
Restrict the lifetime of cached objects
When putting objects to the cache you can restrict their lifetime. In this case, instead of checking the validity of cached objects, you can simply let them expire over time.
Rebuild the cache on non-persistent implementations after server restart
Whether cache is persistent depends on the underlying implementation. For non-persistent implementations the cache must be rebuilt after server restart. See Cache implementations for more.
Get the cache
Achieve an instance of Cache. This is your cache to operate on. Give it a name which must be unique within the system.
- Lines 2, 4-6: Inject CacheFactoryProvider and keep it as a final member of your class.
- Line 9: Fetch the Cache with its name. The cache provider will always return the same instance once it has been created.
All subsequent actions - adding, reading and removing objects - are applied on this
Configure the cache
Magnolia allows to configure a cache factory specifically for each cache. For example you could have a specific configuration for
fooBarCache. When no specific configuration is defined, the
default factory configuration is used.
Example: Extend the
default factory and override the persistence strategy with
none. This persistence strategy allows to cache non-serializable objects.
/modules/cache/config/cacheFactory/caches/fooBarCache node defines the cache name.
fooBarCache is the "name" of the cache which was also used above when acquiring the Cache object within Java code.
Put to cache
Cache knows two methods to append objects.
The identifier of the object to cache
The object to cache
The lifetime of the cached object in seconds.
Tip: The lifetime also can be configured globally, and you can configure a flush policy to clear the cache when some condition is met, or you may want to delete cached objects programmatically (see #remove and #clear below).
Retrieve from cache
There are two methods to retrieve an object from cache.
Returns an object from the cache and blocks all the requests for the same key.
#get when you are unsure whether the desired object is already cached. If the object is not yet cached, you should acquire it by other means and add it to the cache.
It is good practice to call
#put within the same associated try-catch-finally block for the same cache key.
If there is no object for a key, add
null to the cache anyway. This way you can ensure that the service doesn't try to read data for a key without an existing value more than one time
Returns an object from the cache but does NOT block requests for the same key.
#getQuiet to acquire objects which are already cached.
This method is used more to "observe" or manage cached objects than to fetch a specific object. The Magnolia Cache Browser app is using #getQuiet, for instance.
Line 8: Uses
Delete from cache
Remove a single item
Clear complete cache
#clear deletes all items of a specific Cache which is identified by its "name"