+

Search Tips   |   Advanced Search


Cache expire parameters

Use the "expires" parameter in IBM Lotus Web Content Management tags and URLs to specify how long to maintain data in the cache before it is expired.

Once data expires from a cache, the next request for the data will be retrieved from the original server. The expires parameter is not mandatory.

Custom expiring parameters can only be used when a server's default Web content cache is set to none or advanced caching. If basic caching is used as your default Web content cache, custom expiring cannot be used. Even though you cannot use custom expiring with basic caching enabled, you can still use custom expiring (when using the advanced cache) to expire data in the basic cache. Values for the expires parameter can represent either a relative period or an absolute date and time:

Basic cache

  • EXPIRES="ABS {date and time}"

  • EXPIRES="REL {integer}{units}"

Advanced Caching

  • CONTENTCACHEEXPIRES="ABS {date and time}"

  • CONTENTCACHEEXPIRES="REL {integer}{units}"

Data caching

  • CONNECTORCACHEEXPIRES="ABS {date and time}"

  • CONNECTORCACHEEXPIRES="REL {integer}{units}"

Examples:

<CONNECT MOD=Web SRV=HTML ACTION=http://www.ibm.com CACHE=SITE  EXPIRES="REL 9000s">


http://host:port/wps/wcm/connect/library/site/sitearea/content?cache=site&expires="REL 9000s"

In this example, the page http://www.ibm.com will be rendered and stored in the basic site cache. Future requests of the same page will receive the cached page until the data expires. The data is set to expire after 9000 seconds (2.5 hours).


Custom expiring strategies


Specifying an absolute time

An absolute date specifies the date and time the document expires.

To indicate a time use the following format:

For example:

A request for this document after this exact time will cause the document to be flushed from the cache and a new copy retrieved.

When specifying an absolute expiry date, the date must be prefixed with ABS, and the date specified must be in one of the following formats:

The first three date formats are those used in the standard HTTP specification, while the last is a simple, short date format for convenience.

When using absolute times and dates to expire data, cached items remain in the cache until they expire. Once expired, the original item is retrieved on the next request and a copy placed in the cache, but as the absolute time or date has already expired, the item will immediately be expired. Essentially, once expired, an item will not be permanently cached again when using absolute times and dates. All absolute time values are in GMT.


Specifying a relative period

Rather than specifying an absolute time, a relative time can be used to specify that the document will expire some time after the document is placed in the cache, for example a number of hours or days. The actual time the document expires is then calculated from the time the document is retrieved and added to the cache.

Rather than specifying a fixed time for the expiry of cached data, the expiry can be specified relative to the time that the data was added to the cache, for example, a number of hours or days.

To indicate a relative time use the following format:

The space after REL is required.

The integer specifies a whole number of time units. Decimal numbers are not supported. The units are specified by using a single case-insensitive character:


Table 1. Formatting examples
In a connect tag In a URL Request

  • EXPIRES="REL 2M"

  • EXPIRES="REL 9000s"

  • EXPIRES=REL 2M

  • EXPIRES=REL 9000s

The first example indicates an expiry of two months.

The second indicates 9000 seconds (2.5 hours).

By design only seconds, hours, days or months may be specified. Minutes are not supported to simplify the interface (M is used for months). Instead, a multiple of seconds can be used (for example, 300 seconds for 5 minutes).


Parent topic:

Use custom caching