7.3 Web Object Cache

The third type of Oracle Application Server cache, Web Object Cache, is used specifically to support web objects. Web Object Cache is an HTTP-centric Java object caching service for servlets and JSP, provided by the OC4J. We refer to Web Object Cache as HTTP-centric because it typically uses information from the servlet request object, HttpServletRequest , such as the URI, query string, and cookies, to automatically formulate a name to use for storing and retrieving objects in a Java Object Cache.

Web Object Cache caching takes place within the OC4J web container before any content produced from a servlet or JSP is sent. Web Object Cache is best used for expensive-to-create or frequently used Java-generated objects. It isn't a substitute for OracleAS Web Cache, in which rendered content is cached and distributed outside of OC4J. Instead, use OracleAS Web Object Cache only to cache sections of content that need to be merged within an OC4J servlet. Outside OC4J, on the other hand, ESI can be used in OracleAS Web Cache.

A Web Object Cache Java API exists for use in servlets, and a Web Object Cache tag library exists for use in JSPs. A tag library is a set of custom tags that effectively extends the tags available when creating a source file such as an HTML file. These tags are preprocessed by a JSP translator, resulting in a servlet that is then compiled and executed.

Java objects are stored in Web Object Cache using block names . Cache policies determine block naming, as well as expiration rules. These policies can be specified declaratively in a policy descriptor file or programmatically using the API or tag library.

To use Web Object Cache effectively, you must split web pages into blocks so that appropriate parts of dynamically generated page content can be cached to improve performance.

7.3.1 Basic Principles

Web Object Cache consists of two components :

Programming interfaces

These interfaces consist of the Web Object Cache servlet API and the Web Object Cache JSP tag library.

Java object repository

This repository has two possible implementations : Java Object Cache or File System Cache.

The API and the tag library (which uses the API) can be used to programmatically set block naming and expiration policies. In addition, the API offers a set of general-purpose cache storage and retrieval methods . The tag library further abstracts these into specific tags for storing and retrieving String, XML DOM, and serializable Java object types. The tag library also offers an include mechanism that uses Web Object Cache cached content. Web Object Cache provides a special interface class, CloneableCacheObj , which allows the API to completely clone copies of variables to solve the problem of a shared item's being inappropriately modified by multiple users of the item.

The repository used by Web Object Cache can be of any appropriate implementation. As mentioned, two implementations exist:

Java Object Cache

This cache, described earlier in this chapter, provides both a memory- and a disk-based caching mechanism.

File System Cache

This cache is strictly a disk-based caching mechanism.

7.3.2 Cache Organization

When items are cached, they are given either an implicit or an explicit block name:

Implicit block name

Implicit block naming, the default, is controlled by attributes of a CachePolicy object. Block naming attributes can be set programmatically using the API or tag library, or declaratively using a policy descriptor file that is deployed with the web application.

Explicit block name

Explicit naming is performed programmatically using the API or tag library.

You can cache an object with different types of access. The access scope can be session or application:

Session scope

An object cached with session scope is available only within the current HTTP session.

Application scope

An object cached with application scope is available to all HTTP sessions in an instance. If Java Object Cache is used as the repository, and it is configured for distributed mode, application scope objects are available to all instances of OC4J that are part of the same cluster.

7.3.3 Caching Policies

The block naming policy is determined in various ways:

• Using the attributes set in a CachePolicy object

• Using the API or tag library

• Using a policy descriptor file

Sometimes, the policy is determined using both the API or tag library and the policy descriptor file.

An implicit block naming policy allows you to use any combination of the HTTP request information (URI, query string, and cookies) to formulate an appropriate block name. Even combinations that selectively specify some query string parameters or cookies can be configured. This creates a powerful, adaptable mechanism that automatically determines the block name for a cached object, in effect, relieving the programmer from having to create a custom naming mechanism. If you wish, you can set a block name explicitly.

An important part of a cache policy is the expiration policy. The expiration policy is set using an ExpirationPolicy object, which is an attribute of a cache policy. Like a block naming policy, an expiration policy is set either using the API or tag library or with a policy descriptor file. You can use either of two time- related approaches:

• You can set a time-to-live value. When the time-to-live expires , the cached object is invalidated.

• You can set a fixed day-of-the-month, day-of-the-week, and/or time-of-day. Doing so allows you to invalidate a cached object once a month, once a week, or once a day at a specified time.

7.3.4 Cache Invalidation

Invalidation is the process used to flag an object as no longer being available. Invalidating an object doesn't necessarily remove it from the cache. When an object's expiration policy is met, the object is invalidated. An object can also be invalidated explicitly using the API or tag library. Whether an invalidated object is removed from Web Object Cache depends upon the repository. However, once invalidated (if requested from the cache), an object isn't returned from the cache. Instead, it must be recreated and recached. Fortunately, because of the programming interfaces, this happens transparently .

It is also possible to invalidate several objects at a time. The API and tag library provide methods for identifying and invalidating objects using a partial block name or wildcard specification.

7.3.5 Repository Management

Currently, you can use one of the two repositories that exist for Web Object Cache: Java Object Cache or File System Cache. The desired repository for a web application is specified in a cache repository descriptor file that is deployed with a web application. If Java Object Cache is specified, additional Java Object Cache properties must be set in the OC4J instance's global web application descriptor file and a Java Object Cache properties file whose location is specified in that descriptor. If File System Cache is specified, a location for the disk cache must also be specified in the cache repository descriptor.

Of the two implementations, Java Object Cache is faster because it is both a memory-based and a disk-based cache, and it is more manageable because it allows you to set limits on the resources it uses. Java Object Cache can also be configured to replicate its cached objects across clustered OC4J instances. File System Cache is slower because it is only a disk cache, and it is less manageable because it allows you only to configure where to store serialized Java objects. You have no configurable control over how much disk space it may use. In addition, File System Cache's cached objects are available only to the local instance of OC4J.