+

Search Tips   |   Advanced Search

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, in the console, check the option...

Each portlet indicates how long, in seconds, to cache its output using the settings in the portlet deployment descriptor (portlet.xml).

If the portlet descriptor does not provide cache settings, the default behavior indicates the portlet is never cached (value of 0). A value of -1 indicates the portlet cache never expires.

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.

IBM portlets are cached via servlet caching. When we 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 we 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.


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:

The value set specifies seconds.

We cannot widen the cache scope at run time from the setting defined portlet.xml. This means that if the portlet.xml has the cache scope set to private , we cannot overwrite this scope setting to be public at run time. We 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.


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. For more information about how to tune the 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.


Parent Portlet creation basics