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

7.2 Java Object Cache

OracleAS Web Cache improves performance by caching all kinds of
content accessed via HTTP. Two other types of caches, Java
Object Cache and Web Object Cache (described in the next section),
are used specifically to support Java and web objects.

Java Object Cache is a service provided by OC4J. OC4J is the Java servlet, JSP, and
EJB environment provided by Oracle Application Server, and was
described in Chapter 6. Similar to OracleAS Web
Cache, Java Object Cache allows the selective caching of content.
However, Java Object Cache caching is performed within OC4J before
content is generated by Java code. Java Object Cache also provides
disk, pool, and stream-accessed caches in addition to a memory cache.

Figure 7-6 illustrates Java Object
Cache's use in OC4J. An HTTP request to a servlet or
JSP in the web container, or an RMI request to an EJB in the EJB
container, can access a cached object in Java Object Cache. The
object in the cache can be loaded by a cache loader class that, in
turn, can retrieve virtually any information it needs from any
source.

Figure 7-6. Java Object Cache architecture

7.2.1 Basic Principles

Java Object Cache exists to cache
frequently accessed or expensive objects created by Java code. An
expensive object is one that requires a significant amount of CPU
resources or a great deal of time to generate. Any Java object type
can be stored in Java Object Cache.

A programmatically defined hierarchy of namespaces, called
regions, organizes Java Object Cache. Typically,
a region is created for each application. Then one or more
subregions are defined for each part of
an application that uses the cache. Regions or subregions can be
combined to create a
group. Groups allow multiple regions to be
manipulated at the same time.

Java Object Cache can cache objects in four ways:

You can place objects in memory.

You can place objects on disk. OracleAS Web Cache, in contrast,
stores objects only in memory.

You can access objects through a pool mechanism.

You can access objects using streams.

Objects may be placed in the cache automatically by an implementation
of the CacheLoader class, or programmatically using the
CacheAccess class. The following subsections expand
on this very high-level view of Java Object Cache.

7.2.2 How It Works

As mentioned earlier,
Java
Object Cache is organized by regions, subregions, and groups. Regions
define a namespace within the cache. If a region
isn't specified, the default region is used.

The first step in using the cache is to define a top-level region,
which is typically the name of an application. Once a top-level
region has been created, that region can be further subdivided into
subregions. A subregion can also be divided into additional
subregions, creating a hierarchy of regions, as shown in Figure 7-7.

Figure 7-7. Java Object Cache organization example

One or more regions or subregions can be placed into a group. A group
definition allows you to apply caching attributes or to invalidate
cached objects for the regions in a group. A region (or subregion)
can be a member of only one group at a time.

Figure 7-7 demonstrates a possible organization for
Java Object Cache. In this case, the application is called
MyApp. It has several servlets,
MyServlet1, MyServlet2, and
MyServlet3. The cache is organized by creating a
top-level region MyApp. The region is subdivided
into three subregions using the names of the servlets. This creates a
set of namespaces in which objects that need to be shared between
servlets can be stored in region MyApp, while
objects specific to a particular servlet are stored in the
servlets' own region. A
Servlets group has been created that groups the
servlet subregions; this grouping allows all the servlet caches to be
invalidated at once.

7.2.3 Types of Caching

Four types of cache mechanisms exist for Java Object Cache: memory,
disk, stream access, and pool. You can select the mechanism that best
fits your needs and the resource constraints (e.g., available memory
and disk space) of your system. Methods exist that allow you to
update any cached memory, disk, or stream access object.

Figure 7-8 shows the relationship between the four
cache types, described in the following paragraphs.

Figure 7-8. Java Object Cache: cache types

Memory cache

Memory cache is stored in the
JVM's heap. This is the fastest form of cache, but
only if there is enough real memory on the host server so that the
operating system isn't required to use its virtual
memory mechanism that swaps its real memory to disk. If the cost of
creating a memory cached object is significant, you can configure the
cache in such a way that it saves the object to disk if it is
invalidated, then retrieves it from disk when it is needed. Memory
cached objects can be updated by obtaining a private copy of an
object, updating it, and then explicitly placing the object back into
the cache.

Disk cache

Disk cache is stored in a designated
local operating system directory. While not as fast as memory cache,
disk cache has some advantages. Any object that requires a
significant amount of CPU processing time or that requires a great
deal of time to retrieve resources to create, can be cached to disk,
eliminating the cost of recreating the object. A LRU algorithm is
used, which deletes disk objects when space is needed. Like a memory
object, a disk object can be updated by obtaining a private copy,
updating it, and then explicitly placing it into the cache.

Stream access and pool are special cache types that use the memory
cache, the disk cache, or both:

Stream access cache

Stream access cache solves the problem of
dealing with very large objects. This type of cache is accessed using
the Java classes
OutputStream and
InputStream. Class OutputStream
places an object into this type of cache, while
InputStream accesses an object. Stream access
cache objects are automatically loaded into disk cache. How a stream
access object is actually stored is transparent to the application
using the cache. Java Object Cache determines the best storage
methodmemory or disk. This determination is based on the size
of an object and the available resources in Java Object Cache.
Streams can typically access very large objects one small chunk at a
time. Such objects would otherwise require a significant amount of
memory to materialize all at once.

Pool cache

Pool cache solves
the problem of managing a pool of identical resources. Pool cache is
accessed through a check-out/check-in system. A pool object contains
a collection of like objects. An application-defined factory object
creates objects for the collection. The cache provides a minimum and
maximum pool size mechanism that allows you to create an initial
minimum number of objects in a pool and to set a maximum number of
objects allowed in a given pool. A pool cache can also allocate
shared resources such as a custom resource adapter.

7.2.4 Cache Initialization

An
object
can be placed into one of the four cache types automatically using a
CacheLoader object or explicitly using the
CacheAccess.put( )

method. Because placing objects in the cache is done
programmatically, doing so can be coordinated between processes.

When a cache region, subregion, or group is defined, it is given a
set of default attributes. These default attributes, in turn, become
the defaults for an object placed in the cache at that location. The
default attributes can be overridden with object-specific attributes
at the time an object is cached. Some attributes must be defined when
an object is stored in the cache, while others can be modified after
an object is already in the cache.

An object can be loaded automatically by setting its
LOADER attribute to an instance of a custom
CacheLoader
class at the time the object is defined. You create a custom
CacheLoader class by extending the
CacheLoader class, overriding its load(
) method. Then, whenever the object
is accessed, if it doesn't already exist in the
cache, Java Object Cache uses the custom
CacheLoader to load the desired object into the
cache.

An object can be explicitly loaded using the
CacheAccess.put( ) method. This requires you to
create the object, and then pass it to the cache as a parameter of
the put( ) method. There are drawbacks to explicit
loading; in particular, you will have to detect and reload the object
explicitly if it is invalidated. An event-handling mechanism, the
interface
CacheEventListener, exists to help with this cache
management issue.

After an object is defined by including a LOADER
attribute or is placed into a cache explicitly, it can be accessed
using the CacheAccess.get( ) method. However, two
factors affect its visibility within an application:

The Java class loader (not the cache loader) used to load the classes
placed into the cache

The value of the
DISTRIBUTE attribute

Where a particular class loader exists in the class loader hierarchy
determines the visibility of the objects it loads. For an object to
be visible in both the web and EJB containers, or even shared between
servlets (and JSPs), a system class loader (not a servlet class
loader) must load it. This means that any classes used for objects
that will be cached in Java Object Cache and shared between servlets,
etc., must be placed on a class path that is available to the
application server, not just to a web application in a web container.

A cached object's DISTRIBUTE
attribute determines whether the object is replicated across
clustered instances of OC4J. If OC4J is clustered, and if Java Object
Cache is configured as a distributed cache, any object that has the
DISTRIBUTE attribute set will be replicated to
each instance of OC4J and will therefore be accessible to all.

7.2.5 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. An
invalidated object remains in the cache until the resources it has in
use are required by Java Object Cache to cache another object. If an
object that is currently invalidated is requested, it will be
reloaded if its LOADER attribute is set, or it
will throw a CacheException error.

Cached objects can be implicitly or explicitly invalidated:

Implicit invalidation

Implicit invalidation takes place
automatically if you have set a time attribute. Two attributes
control time invalidation: time-to-live and idle time. You can set
the time-to-live or idle time by calling the appropriate method when
an object is defined or after it has been placed into the cache. When
the time-to-live expires, or when the idle time is reached, the
associated object is invalidated.

Explicit invalidation

An object can be explicitly invalidated by calling the
CacheAccess.invalidate( ) method. An object can be
removed from the cache altogether by calling
CacheAccess.destroy( ) instead of
invalidate( ).

You can set invalidation rules for entire regions, subregions, or
groups by setting the time-to-live or idle time attributes for the
desired organizational unit. You can also explicitly invalidate a
region, a subregion, or a group.

7.2.6 Cache Management

Java
Object Cache's global configuration is managed
manually by setting properties in its configuration file, or
programmatically using the Cache class. Unlike
OracleAS Web Cache, Java Object Cache isn't managed
via Application Server Control or DCM. Either the manual or the
programmatic method allows you to specify the
cache's memory size, its disk size and location, the
cache cleanup interval, and other attributes, as well as to configure
the cache as a local or distributed cache.

The contents of a local cache are available only to programs run on
the OC4J instance where Java Object Cache resides. When a cache is
configured as a distributed cache, its contents are replicated to
every other distributed Java Object Cache in the same cluster. Using
a distributed cache requires a great deal more resources, so it may
make more sense to use a local cache even in a clustered
environment.