The Magnolia cache module is based on EhCache, an open course Java distributed cache. We ship an ancient ehcache 1.5. This brings several drawbacks nowadays, among others performance, integration or scalability options. This page aims to evaluate possibilities of upgrading to the current 2.7 release. The task is logged as. Ehcache is available under an Apache 2 license.
Ehcache 2.7 requires slf4j update from current 1.6.4 (as done because of last JR update) to 1.6.6. Since Ehcache 1.7.1, it depends on slf4j for logging. Since Ehcache 1.7.1, it depends on slf4j for logging
The new release doesn't seem to depend on the backport-util-concurrent and jsr107cache libraries the former one did.
It requires Java 1.5 or 1.6 at runtime.
As such we can get rid of the backport-util imports in favour of java utils.
Creation of, access to, and removal of caches is controlled by the net.sf.ehcache.CacheManager. CacheManager supports two creation modes: singleton and instance.
Ehcache 1.5 allowed any number of CacheManagers with the same name (same configuration resource) to exist in a JVM. Therefore, each time new CacheManager(...) was called, a new CacheManager was created without regard to existing CacheManagers. info.magnolia.module.cache.ehcache.EhCacheFactory simply instantiates a new CacheManager on any module start.
Since Ehcache 2.5.2 the behavior of the CacheManager creation methods is as follows:
As far as I can see we support three kinds of CacheManagers to be provided by the EhCacheFactory:
- the one initialized by Ehcache directly - the initial ConfigurationFactory, an ehcache utility that configures a bean from the default ehcache|failsafe.xml, sets the configuration source for CacheManager by its own nowadays, hence we don't have to take care of it by our own anymore. Additionally there should be no need to call this upon each and every start.
- the one that listens to /modules/cache/config/cacheFactory/defaultCacheConfiguration configuration - if this exists, we override the previous one with this Magnolia specific settings that can be reconfigured runtime. After any configuration changes we might reuse its already existing CacheManager but inject a new configuration to it.
- the one that uses DiskStore - the diskStore path specified in each CacheManager configuration should be unique. When a new CacheManager is created, a check is made that there are no other CacheManagers using the same diskStore path. If there are, a CacheException is thrown.
Each CacheManager requires its own configuration.
The CacheManager's configuration source, an informative description of the source, preferably including the resource name and location, is not represented by a String anymore, but is abstracted by an encapsulating net.sf.ehcache.config.generator.ConfigurationSource class. It also doesn't substitute a CacheManager name (.setName(string) should be called for each CacheManager explicitely, while each name must be unique).
This internal Content2BeanTransformer on demand is still needed.
An element is an atomic entry in a cache. There seem to be no changes on the API field since 1.5. Object based elements are used.
The cache module already provides its own support for terminating stale requests and let them timed out. Moving to what ehcache comes with is perhaps not necessary at this point.
- changed meaning of maxElementsInMemory=0 for MemoryStore to be unlimited.
- extended existing in-memory and on-disk concepts to include off-heap as an additional possible location.
EhCache change log
There is a magnolia-4.5.x-MAGNOLIA-3535 branch created for this task.