Starting in 6.1 there will be a change in how caches are configured for the portal and plugins. This new mechanism only applies for ehcache caches.

Changes to default cache configuration:

Configuring caches for clustering is simpler. Instead of having to switch config files in portal.properties, the default Liferay cache configurations will be loaded and automatically configured. The portal will configure ehcache for not clustered, clustered using RMI, and clustered using Cluster Link. Before the difference between liferay-multi-vm.xml and liferay-multi-vm-clustered.xml was the presence of RMI cache listeners designed to replicate the cache across a cluster. This adds unnecessary overhead for a non-clustered deployment, hence the different configuration files. Now the portal will automatically remove the relevant listeners if the portal is not in a clustered configuration. Configurations regarding enabling and using Cluster Link replication remains the same.

These changes do not prevent you from defining a custom cache configuration file. If you decide to configure your own instead of using the default Liferay one, simply direct the ehcache.multi.vm.config.location property to go to your configuration file. Ensure that your custom file is located on a different path or a different file name as the portal may confuse it with the default configuration file. The portal will not alter a custom configuration. This means that if you decide to use a custom configuration you will have to decide on and configure your clustering settings in the configuration file as before. The same logic applies for hibernate cache configurations. The change has no impact on single-vm caches as they are not replicated across a cluster.

New plugin-based cache configuration:

You can now dynamically change any cache configuration during runtime via plugins. Before the only way to change a cache configuration at runtime was via the cache MBeans, but this configuration was transient and was restricted to the properties that ehcache allowed you to change after a cache is initialized. This mechanism was also restricted to only the single and multi vm caches as Hibernate caches were not exposed.

Plugin cache reconfiguration allows:

Reconfigure any cache (Single VM, Multi VM, and Hibernate)

Creating new caches, including caches for ServiceBuilder services introduced in a plugin

This capability can be leveraged in any plugin.

To use in a plugin you simply need to add a portlet.properties file to your plugin that defines the same properties that are used in the core portal to define cache configuration file location:

net.sf.ehcache.configurationResourceName

ehcache.single.vm.config.location

ehcache.multi.vm.config.location

The location defined in the above properties for a plugin is defined relative to the plugin's context.

Other notes:

Ehcache does not allow changes to most settings in a cache once the cache has started storing objects. As a result, reconfiguring a cache will result in cached objects being flushed.

It is recommended that cache overriding be carefully managed as plugin loading order is not gauranteed. The final plugin to be loaded will determine the cache configuration.