7.2 Java Object Cache | Oracle Application Server 10g Essentials

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 method ”memory 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.