About Pagelet/Portlet Caching
Caching is the functionality that allows Oracle WebCenter
Interaction and Oracle WebCenter Ensemble to request pagelet/portlet
content, save the content, and return the saved content to users when
appropriate. The importance of caching cannot be overstated.
Efficient caching makes every web application faster and less expensive.
The only time content should not be cached is if the data must be
continuously updated. If every pagelet/portlet had to be freshly generated
for each request, performance could become unacceptably slow. Oracle
WebCenter Interaction and Oracle WebCenter Ensemble rely on caching
to improve performance. Pagelet/portlet content is cached and returned
when later requests match the cache’s existing settings.
Caching is indexed on the settings sent by the pagelet/portlet.
When the Oracle WebCenter Interaction or Oracle WebCenter Ensemble
gateway server processes a request for a page, it looks individually
at each pagelet/portlet on the page and checks it against the cache.
The process can be summarized as follows:
- The gateway server assembles a cache key used to uniquely identify
each pagelet/portlet in the cache.
- The gateway server checks the cache for a matching cache key entry:
- If the gateway server finds a match that is not expired, it returns
the content in the cache and does not make a request to the remote
server.
- If there is no matching cache key for the pagelet/portlet or if
the cache key has expired, the gateway server makes a request to the
remote server. If the matching cache entry uses ETag or Last-Modified
caching, it also sends the appropriate caching header to the remote
server in the request.
- The response comes back from the remote server; the gateway server
checks for caching headers:
- If the headers include an Expires header, the gateway server stores
the new pagelet/portlet content (along with a new expiration date)
in its cache.
- If the headers use ETag or Last-Modified caching, the existing
cache entry might be revalidated (in the case of ‘304-Not Modified’)
or new pagelet/portlet content might be stored in the cache.
Oracle WebCenter Interaction and Oracle WebCenter Ensemble cache
gatewayed content to complement, not replace, browser caching. Public
content is accessible to multiple users without any user-specific
information (based on HTTP headers). The gateway server calculates
the cache headers sent to the browser to ensure that the content is
properly cached on the client side.
Oracle WebCenter Interaction and Oracle WebCenter Ensemble cache
all text (i.e., nonbinary) content returned by GET requests. Even
if gateway caching is disabled (via PTSpy), pagelet caching still
takes place. Gatewayed content can be cached by a proxy server or
by the user’s browser. Beware browser caching of gatewayed content;
it is a good idea to clear your browser cache often during development.
An incorrectly set Expires header can cause browsers to cache gatewayed
content.
The pagelet/portlet cache contains sections of finished markup
and sections of markup that require further transformation. Post-cache
processing means content can be more timely and personalized. Adaptive
tags enable certain pagelets/portlets (for example, Community banners)
to be cached publicly for extended periods of time and yet contain
user specific and page-specific information, as well as the current
date and time.
For details, see the following topics:
For a full explanation of HTTP caching, see RFC 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616.html).
- About Pagelet/Portlet Caching StrategiesPagelet/portlet caching is controlled both by the programmer and by the administrator who registers the pagelet/portlet in Oracle WebCenter Interaction or Oracle WebCenter Ensemble. Each and every pagelet/portlet needs a tailored caching strategy to fit its specific functionality.
- Pagelet/Portlet Cache KeyThe cache key for a pagelet/portlet entry in Oracle WebCenter Interaction or Oracle WebCenter Ensemble consists of these values.
- Implementing Portlet CachingCaching on the Portal Server can be set in two ways: programmatically through HTTP headers and/or using the administrative settings in the Web Service editor. You should always implement caching programmatically, although the administrator can still choose to override caching through administrative settings.
- Setting HTTP Caching Headers - Cache-ControlThe Cache-Control header can be used to expire content immediately or disable caching altogether. The value of this header determines whether cached pagelet/portlet content can be shared among different users.
- Setting HTTP Caching Headers - ExpiresThe Expires header specifies when content will expire, or how long content is “fresh.” After this time, the portal server will always check back with the remote server to see if the content has changed.
- Setting HTTP Caching Headers - Last-Modified and ETagThe Last-Modified response header specifies the last time a change was made in the returned content, in the form of a time stamp. ETag values are unique identifiers generated by the server and changed every time the object is modified. Either can be used to determine if cached content is up to date.
- Configuring Oracle WebCenter Interaction Portlet Caching SettingsIn Oracle WebCenter Interaction, the HTTP Configuration page of the Web Service editor allows portal administrators to set minimum and maximum validation times for cached portlet content.
