Caching content helps improving the Portal response time for users. It also helps reducing the load on servers.
The Portlet Specification defines an expiration based caching mechanism. This caching
mechanism is per portlet. Cached content must not be shared across different user clients
displaying the same portlet for the private cache scope.
Portlet containers are not required to implement expiration caching. Portlet containers
implementing this caching mechanism may disable it, partially or completely, at any time
to free memory resources.
Portlets that want their content to be cached using expiration cache should define the
default duration (in seconds) of the expiration cache in the deployment descriptor. The
portlet container should treat portlets with no default duration in the deployment
descriptor as always expired as default.
The following is an example of a portlet definition where the portlet defines that its
content should be cached for 5 minutes (300 seconds) and must not be shared across
users.
A portlet may programmatically alter the expiration time or caching scope by setting a property in the RenderResponse or ResourceResponse object using the EXPIRATION_CACHE or CACHE_SCOPE constant defined in the MimeResponse interface in forwarded or included servlets/JSPs. Inside the portlet the CacheControl object is available via the MimeResponse for setting the expiration time or caching scope via the calls setExpirationTime or setScope.
The portlet should set the expiration time or caching scope before writing to the output stream as otherwise portals / portlet containers may ignore the values. If the expiration property is set to 0, the returned markup fragment should be treated as always expired. If the expiration cache property is set to –1, the cache does not expire. If during a render invocation the expiration cache property is not set, the expiration time defined in the deployment descriptor should be used. If the caching scope is set to PRIVATE_SCOPE the cached data must not be shared across users. If the caching scope is set to PUBLIC_SCOPE the cached data may be shared across users. The private scope is the default scope if no scope is provided in the deployment descriptor or via the RenderResponse or ResourceResponse.
Important Note : Liferay only support the private scope for now.
If the content of a portlet is cached, the cache has not expired and the portlet is not the
target of an action or event the request handling methods of the portlet should not be
invoked as part of the client request. Instead, the portlet-container should use the data
from the cache.
In Liferay, the Expiration cache implementation is made by a Servlet Filter called FilterCache.
If your want your portlet to be cached by this filter, you will have to set
the layout-cacheable value in your liferay-portlet.xml.
And of course, if you want to use the CacheFilter provided by Liferay, you will have to declare this filter and the related filter mapping in your web.xml.
During the deployment of your war, Liferay 6.1 and upper make copy of your web.xml and add many more filter to a new liferay-web.xml. If you let's this default behaviour, you will have to face error raise by InvokerFilte. So in order to disable the use of liferay-web.xml, just add the following line to the file 'docroot/WEB-INF/liferay-plugin-package.properties' in your project.
In Liferay, in order to activate the expiration cache you will have to change the default configuration of your liferay portal. To do that add the following lines to your portal-ext.properties that must be located under \webapps\ROOT\WEB-INF\classes.
In the same portal-ext.properties, you will also have to inform the portal where is located your ehcache configuration cache.
Important Note : Liferay is not supported this Validation-Based caching behaviour. http://issues.liferay.com/browse/LPS-28799
Validation based caching strategy extends the expiration caching strategy by allowing portlets to validate the cached content after the expiration time has passed. If a portlet finds that the cached content is still valid,then the portlet instructs the portlet container to use the cached content for another expiration period. If the cache becomes invalid, then the portlet generates fresh content.
For more details see Portlets in Action.