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 WAS admin console. Refer to the WAS information center for detailed instructions.

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

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, which is also the behavior if the portlet descriptor does not provide cache settings. Both standard and IBM portlet deployment descriptorss 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.

By more precise detail, IBM portlets are cached via servlet caching. When you enable fragment caching, servlet caching is also enabled, as fragment caching requires servlet caching..

Modify 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);

Modify the cache scope at run time is restricted.

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's getLastModified() method, the time stamp is set to an attribute in the portlet's 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, used by the portal server to determine how the page is cached on a remote proxy server. Refer to the section about how to tune the portal for more information on how remote caching is determined for the page. 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 descriptors, in the same way as noted previously under "local cache". These cache settings can be modified in the portal administration.

Related

• IBM WebSphere Developer Domain - Portal Zone: WebSphere Portal Zone
• Customize the portal

Parent: Understand the basics