Caching portlet output

Portlet output can be cached at the local application server or using a remote proxy server.

Local cache settings

If fragment caching is enabled on the application server, the local cache holds the complete output of the portlet by portlet window and portlet state. If the portlet is included on a page, and the cache contains valid markup for the requested portlet state, the portlet code is not called, but cached content is returned. An action or event on the portlet invalidates all cached content for the affected portlet window.

To enable local caching, check the Enable Portlet Fragment Cache option in the WebSphere® Integrated Solutions Console. For detailed instructions see the WebSphere Application Server information center and the links at the end of this topic.

The portlet indicates how long, in seconds, its output should be cached in the portlet deployment descriptor.

Standard portlet cache settings
   <expiration-cache>300</expiration-cache>

<cache-scope>private</cache-scope>
IBM portlet cache settings
  <cache>
    <expires>300</expires>
    <shared>no</shared>
  </cache>

A value of -1 indicates that the portlet cache never expires. A value of 0 indicates that the portlet is never cached. This is also the default setting and behavior if the portlet descriptor does not provide cache settings. Both standard and IBM portlet deployment descriptors can also specify a cache scope that indicates whether cached content is public (shared) or per user. Cache settings for standard portlets can be modified in the portal administration portlet Manage Portlets.

Note: As described in the WebSphere Application Server information center, IBM portlets are cached via servlet caching. When you enable portlet fragment caching, servlet caching is also enabled, as fragment caching requires servlet caching. Conversely, if you disable servlet caching, portlet caching is also disabled. The cache setting applies globally. Caching is enabled per Java servlet or portlet container. This means that if you enable portlet caching, it is applied to any and all portlets across all web applications. As servlet caching is enabled automatically as a prerequisite to portlet caching, all servlet-based web applications will be cacheable as well. As a result, a servlet-based web application that defines a custom cachespec.xml file will now have that cachespec.xml take effect, whereas previously it was dormant if servlet caching was not explicitly activated. This includes all servlets in non-portal areas within the complete WebSphere Application Server environment.
Modifying the local cache at run time
For standard portlets, the portlet window can modify the expiration time at run time using the CacheControl object, as follows:
renderResponse.getCacheControl().setExpirationTime(3000);
The value that you set specifies seconds.
Note: You cannot widen the cache scope at run time from the setting defined in the portlet.xml file. This means that if the portlet.xml has the cache scope set to private , you cannot overwrite this scope setting to be public at run time. You can narrow the scope from a public setting in the portlet.xml to private at run time.

The getLastModified() method of the IBM portlet API enables the portlet developer to inform the container when the current cache entry for the portlet should be invalidated, and therefore the portlet's content should be refreshed. The following example shows how a portlet that caches its output can change its content immediately to provide additional output. In the portlet getLastModified() method, the time stamp is set to an attribute in the portlet session.

Figure 1. getLastModified() example
    public long getLastModified(PortletRequest request) {

        PortletSession session = request.getPortletSession(false);

        if(session == null) {
            return System.currentTimeMillis();
        }
        if (session != null) {
            Long lastModified = (Long) session.getAttribute(LAST_MODIFIED);
            if (lastModified != null) {
                return lastModified.longValue();
            }
        }
        return -1;
    }

Remote cache settings

In an environment where a remote proxy server is used for caching, standard portlets can indicate cache settings, which are used by the portal server to determine how the page is cached on a remote proxy server. For more information about how to tune your portal and how remote caching is determined for the page see WebSphere Portal the performance tuning guide. IBM portlets cannot provide individual cache preferences for the remote cache.

Standard portlets specify cache expiration and cache scope for remote caching in the deployment descriptor, in the same way as noted previously under "local cache". These cache settings can be modified in the portal administration portlet Manage Portlets.

Related information