You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

 

Rationale

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 Unable to locate Jira server for this macro. It may be due to Application Link configuration. . Ehcache is available under an Apache 2 license.

 

Dependencies

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.

 

API changes

CacheManager

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:

CacheManager.newInstance(Configuration configuration) – Create a new CacheManager or return the existing one named in the configuration.
CacheManager.create() – Create a new singleton CacheManager with default configuration, or return the existing singleton. This is the same as CacheManager.getInstance().
CacheManager.create(Configuration configuration) – Create a singleton CacheManager with the passed-in configuration, or return the existing singleton.
new CacheManager(Configuration configuration) – Create a new CacheManager, or throw an exception if the CacheManager named in the configuration already exists or if the parameter (configuration) is null.

 

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.


Configuration, ConfigurationSource

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).

 

CacheConfigurationTransformer

This internal Content2BeanTransformer on demand is still needed.


Cache Element

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.


BlockingCache

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.

Other notes

  • 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

Git

There is a magnolia-4.5.x-MAGNOLIA-3535 branch created for this task.

 

  • No labels