Portal, V6.1

---

 

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 Servlet Caching and Portlet Caching options in the console for the application server. See the WAS information center for detailed instructions.

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

Modifying the local cache at runtime

For standard portlets, the portlet window can modify the expiration time at runtime using the CacheControl object, as follows:

renderResponse.getCacheControl().setExpirationTime(3000);

Modifying the cache scope at runtime is restricted in WebSphere Portal 6.1, see "Known limitations for standard portlets.

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, which are 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 your 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 descriptor, in the same way as noted above under "local cache". These cache settings can be modified in the portal administration.

 

Related information

• IBM WebSphere Developer Domain - Portal Zone: WebSphere Portal Zone

• Customizing the portal

 

Parent topic

Understanding the basics

---