Developing exteNd Director Applications
CHAPTER 14
This chapter describes how to handle data caching in exteNd Director applications. It has these sections:
Data caching provides a way to manage the temporary storage of application data. The most common purposes for managing data caches are:
exteNd Director supports data caching at different application levels, including HTTP request, application session, portlet application, and server-lifetime (for server clusters).
The EbiCacheManager interface allows you to manage session-level and server life-time data. It provides two cache mechanisms:
The object cache container stores all objects in memory, regardless of the size of the content. It is used when the putObjectInCache() method is called from the cache holder object, described in the next section (About the cache holder). The object cache does not require cached objects to be serializable.
Use the object cache container if you are not primarily concerned about the size of the cached content and/or if you need the ability to store nonserializable objects.
How it works The object cache container uses the maximum number of objects specified in the cache configuration to determine when to remove the least-used objects from its cache. In cases where the maximum number of objects has not been reached but memory is running low, the object cache container removes the least-used objects from its cache.
The memory cache and disk cache container mechanism stores objects either in memory or on disk depending on the size of the object. This caching mechanism requires cached objects to be serializable. It is used when the putValueInCache() method is called from the cache holder object. (See About the cache holder.)
Use this implementation when you want to remove larger objects from memory and cache them on disk, keeping in mind that the objects must be serializable.
How it works The memory and disk cache containers use a maximum byte-size value to determine whether to cache items in memory or larger items on disk. You can use the Cache Manager to configure this value.
NOTE: The object cache and the memory cache each maintain their own cache in memory, and are managed separately.
You can reconfigure the default Cache Manager settings using one of these methods:
Cache settings in the DAC You can use the Cache settings in the Director Administrator Console (DAC) to configure the Cache Manager. Values set in the DAC are not stored beyond the current server session.
For more information, see Using the General Configuration Section of the DAC.
ContentCache settings in config.xml To make persistent changes, edit the ContentCache settings in config.xml, located in the FrameworkService-conf directory in your project. For a description of the settings, see Using the General Configuration Section of the DAC.
The EbiCacheHolder interface defines caching methods for the session-lifetime cache holder (EbiSession) and the server-lifetime cache holder (EbiSrvLifetimeCacheHolder). A cache holder can store content in the object cache container or the jointly managed memory and disk cache containers, as described in the preceding section. (About the Cache Manager.)
To access the session cache, call the appropriate method in EbiSession. To access the server-lifetime cache, call the appropriate method in EbiSrvLifetimeCacheHolder. Here are some of the methods (inherited form EbiCacheHolder) on both of these objects:
You can access request parameters directly from the application's request object or use temporary values in the context object.
NOTE: If you need to cache request values for a session, for session-level fail over for example, you must store them on the whiteboard. For more information, see Using the whiteboard.
Request attributes are stored in the associated servlet or portlet request object: HttpServletRequest, ActionRequest, or RenderRequest. You can access them using getAttribute() and setAttribute() on the appropriate request object. Objects stored in the request object are available for the duration of a single request. If you want to persist a value for subsequent requests, use the context object as described in the next section.
You can access the underlying request object from the EbiRequest interface, which provides the wrapper objects for each request type.
For more information, see EbiRequest in the API help system.
You can also access request attributes as temporary values using get/setTemporaryValue() on EbiContext. The lifetime of the temporary value is the same as the lifetime of the EbiContext object.
For example, this code gets a request parameter and uses it to set a temporary value. The key is stored in the constant USER_CHOICE:
String userChoice =
context.getEbiRequest().getParameter(USER_CHOICE);
if (userChoice != null)
context.setTemporaryValue(USER_CHOICE, userChoice);
This method gets the value:
String choice = (String) context.getTemporaryValue(USER_CHOICE);
This section describes ways to cache session-level data.
You can use the Cache Manager and session cache holder to cache nonserializable or serializable session objects in memory or on disk. You can cache data in either the object cache or the memory and disk integrated cache by using the appropriate methods on EbiSession.
For more information, see About the Cache Manager and About the cache holder.
The whiteboard is a session-level cache for storing serializable objects. The whiteboard can be used to access commonly used values and for session-level failover. You can access the whiteboard using these methods on EbiContext:
session-level failover Session values that you want to preserve for session-level fail over must be cached on the whiteboard. Session-level failover refers to the ability of an application to retain temporary user data (state) across server failures in a cluster. The data is stored in a persistent storage repository (such as a database or file system shared by the servers in the cluster) so that it can be recovered by any server in the cluster in the event of a server failure.
IMPORTANT: Make sure the objects cached in the whiteboard are implementing java.io.Serializable. Otherwise, they will not be recovered if the session fails.
Each application server has its own level of support for session-level failover. Refer to your application server documentation for details.
For information regarding session-level failover using the exteNd Application Server, see the chapter on server implementation notes in Application Server Facilities Guide.
Portlet application data can be cached in a PortletSession object or in a PortletContext object, as defined in the javax.Portlet specification.
The PortletSession interface defines two scopes for caching objects:
APPLICATION_SCOPE Any object stored in the session using this scope is available to any other portlet that belongs to the same portlet application that handles a request identified as being a port of the same session.
PORTLET_SCOPE Objects stored in the session using this scope must be available to the portlet during requests for the same portlet window.
You can access values in either scope using setAttribute() and getAttribute() on the PortletSession object by passing in the scope.
For more information, see the API documentation for PortletSession.
NOTE: You can also access these scopes using the exteNd Director scoped paths feature. For more information, see Working with Scoped Paths and XPaths.
Attributes cached in the context are global for all users and all Web components in the portlet application. You can access these values using setAttribute() and getAttribute() on the PortletContext object. For more information, see the API documentation for PortletContext.
Objects stored in the server-lifetime cache can be cached for enhancing performance and can be synchronized with other servers in a server cluster environment. This function is handled jointly by the exteNd Director Cache Manager and Cache Coordinator.
You can cache objects in the server-lifetime cache by calling putObjectInCache() from the server-lifetime cache holder (EbiSrvLifetimeCacheHolder). The cached objects do not need to be implemented as javax.io.Serializable.
The server life-time cache is managed by the Cache Manager on each server. The cached objects are synchronized with the latest data stored in the database in a clustered environment. This function is handled by the Cache Coordinator.
For more information, see Using the Cache Coordinator.
exteNd Director provides built-in server-lifetime cache holders for different type of subsystem runtime data, including:
These caches are listed in the Director Administration Console under the Cache Holders section.
For more information, see Using the General Configuration Section of the DAC.
Copyright © 2003 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...