On occasion, when working with very large data-sets, the APIs of certain repositories take time to fetch large chunks of data. When this happens with data that is relatively static(say, needs only occasional updates), it is more useful to cache this information in OpenContent and have the code pull from it whenever possible. To facilitate this, an Eager Caching framework has been implemented and is in use today! Hot swapping was a necessary feature for this implementation, and so if a cache has been generated, it is available even while new ones to replace it are being generated; if a cache implementation does not require this, this can be overridden.

The Abstract Eager Cache is the bean which most eager caching implementations will want to inherit and implement. The core of any of the Eager Cache implementations is the doGenerateCache method; this method should perform the repository-specific(or OpenContent-specific) logic to get the data available from the cache.

At present, there's a property for the cache that defaults to false, that the cache does not generate on startup. This can be overridden in the bean definition for a cache implementation, if it is necessary that the cache is always available.

Many use cases, however, do not require the cache immediately but want the cache to generate arbitrarily; for these, REST endpoints are defined which get the cache of a given name and generate the cache upon calling it.

Actual accessing of the cache can be done via. the CoreContext.getEagerCacheService.getCache call. If the cache does not exist, it will throw an error; if the cache might exist, you can check with the "cacheExists" call.

Similarly, the getValue function returns the specified value for a given key. If no key is defined, it is up to the cache on how to handle this; some may want to cache the data then return it, others may error.

When implementing the Abstract Eager Cache, you should provide the types you expect of the key and value; this way, when using the cache, you don't need to keep track of any additional type information, and the cache should know what it stores. If the cache does not know, that should be made clear in the contract.

Note that the only necessary function to define is the doGenerateCache method; the remaining methods have basic implementations provided.

An example of the implementation of this cache is available in the AlfrescoEmbEagerUserCacheImpl; this implementation provides a definition for the doGenerateCache, as well as overrides of getValue and the like.

It's use is typically of more interest. In AlfrescoEmbPicklistImpl#getGroupPicklistItems , the code tries to get the cache and, if it exists, tries to get the group from it, before it even attempts a Lucene search or getContainedAuthorities call against Alfresco; since these calls can take a significant amount of time, this provides huge savings in large environments.

As well, this helps to solidify an interface; note that using this cache allows all**** the information to be available at runtime, rather than needing to go back to the API to populate usernames, as the default implementation performs.