Oracle Application Server 10g Essentials [Electronic resources] نسخه متنی

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.