Dynamic cache works within an application server Java virtual
machine (JVM), intercepting calls to cacheable objects. For example,
it intercepts calls through a servlet service method, or a command
execute method, and either stores the output of the object to the
cache or serves the content of the object from the dynamic cache.
The dynamic cache engine is the default cache
provider for the dynamic cache APIs and framework. However, starting
with Version 6.1.0.27, dynamic cache allows WebSphere eXtreme Scale,
which is the is the strategic direction for caching for the WebSphere
products, to act as its core caching engine.
Configuring the dynamic cache to use WebSphere
eXtreme Scale lets you leverage transactional support, improved scalability,
high availability, and other WebSphere eXtreme Scale features without
changing your existing dynamic cache caching code. If you are currently
using the default cache provider, you can use the administrative console
or wsadmin commands to replace the default dynamic cache provider
with the WebSphere eXtreme Scale dynamic cache provider. You do not
have to make any changes to your dynamic cache programming model.
See the topic WebSphere eXtreme Scale dynamic cache provider in
the WebSphere eXtreme Scale Version 7.0 Information Center
for an overview of the WebSphere eXtreme Scale dynamic cache provider.
WebSphere eXtreme Scale can operate as an
in-memory database processing space. You can use this processing space
to provide in-line caching for a database back-end, or as a side cache.
in-line caching uses WebSphere eXtreme Scale as the primary means
for interacting with the data. When WebSphere eXtreme Scale is used
as a side cache, the back-end is used in conjunction with WebSphere
eXtreme Scale.
Functional advantages of using
the WebSphere eXtreme Scale dynamic cache provider
The WebSphere
eXtreme Scale dynamic cache provider:
- Supports memory-to-memory replication for sessions.
- Can handle all of the generic data and session caching needs
of your applications.
- Enables your applications to leverage system memory without using
SAN or storage solutions to host a dynamic cache disk cache.
- Provides a scalable replicated cache with a configurable number
of replicas, thereby eliminating the need to use the data replication
service (DRS), which the default cache provider uses. Use of DRS sometimes
causes performance problems.
- Can be configured with additional WebSphere eXtreme Scale containers
at runtime, thereby increasing your cache capacity, and preventing
performance issues that sometimes occur when you use DRS. WebSphere
eXtreme Scale automatically redistributes the partitions as new containers
are added to the grid.
- Provides better caching qualities of service and control, than
the default cache provider.
- Uses the same runtime monitoring and administration tools as the
classic dynamic cache. These tools, such as the cache monitor and
the dynamic cache runtime MBean, work the same way when dynamic cache
runs on top of WebSphere eXtreme Scale, as when they are used with
classic dynamic cache.
Functional differences between
the default cache provider and the WebSphere eXtreme Scale dynamic
cache provider
Following is a list of functional differences
between the default cache provider and the WebSphere eXtreme Scale
dynamic cache provider:
- WebSphere eXtreme Scale dynamic cache provider does not include
disk cache support because all cache data is kept in memory. Therefore,
the disk caching custom properties are not supported.
- WebSphere eXtreme Scale dynamic cache provider does not support
the following features:
- DistributedNioMap - skipMemoryAndWriteToDisk
- DistributedMap and DistributedNioMap alias
- Disabling dependency IDs or templates
- WebSphere eXtreme Scale dynamic cache provider does not support
DRS style replication. Therefore, the DRS custom properties are not
supported.
When you use the WebSphere eXtreme Scale dynamic cache
provider, replication configuration is controlled by the WebSphere
eXtreme Scale deployment and definition files. See the topic Configuring the dynamic cache provider for WebSphere
eXtreme Scale in the WebSphere eXtreme Scale Version 7.0 Information Center
for more information about replication.
- DistributedNioMapObject.release() is not called to release the
byteBuffers for NIO buffer Management.
- WebSphere eXtreme Scale dynamic cache provider has limited PMI
support. Certain PMI and MBean counters are no longer valid. See the
topic Configuring the dynamic cache provider for WebSphere
eXtreme Scale in the WebSphere eXtreme Scale Version 7.0 Information Center
for more information.
- When firing any event, ObjectGrid always sets the sourceOfInvalidation
to REMOTE
- You can use the DynaCache API to register event listeners regardless
of which cache provider you are using. However, if you use WebSphere
eXtreme Scale dynamic cache provider, the event listeners work as
expected for local in-memory caches. When co-located containers are
being used, events are thrown on the machine where the request that
caused the event is serviced instead of on the machine where the request
originated. For example if an invalidate request is issued on Server
A and the cache entry that gets invalidated is actually stored on
Server B, then the event will be fired on Server B. With the default
dynamic cache provider, the event is fired on Server A. When stand-alone
containers are being used, no events are fired through the DynaCache
event listener API.
Key concepts pertaining to the dynamic cache service
Explore
the key concepts pertaining to the dynamic cache service, which improves
performance by caching the output of servlets, commands, Web services,
and JavaServer Pages (JSP) files.
- Cache instances
- An application uses a cache instance to store, retrieve, and share
data objects within the dynamic cache.
- Using the dynamic cache service to improve performance
- Caching the output of servlets, commands, and JavaServer Pages
(JSP) improves application performance. WebSphere® Application Server consolidates several
caching activities including servlets, Web services, and WebSphere
commands into one service called the dynamic cache. These caching
activities work together to improve application performance, and share
many configuration parameters that are set in the dynamic cache service
of an application server.
- Configuring dynamic cache to use the WebSphere eXtreme Scale dynamic
cache provider
- Configuring the dynamic cache service to use WebSphere eXtreme
Scale lets you leverage transactional support, improved scalability,
high availability, and other WebSphere eXtreme Scale features without
changing your existing dynamic cache caching code.
- Configuring servlet caching
- After a servlet is invoked and completes generating the output
to cache, a cache entry is created containing the output and the side
effects of the servlet. These side effects can include calls to other
servlets or JavaServer Pages (JSP) files or metadata about the entry,
including timeout and entry priority information.
- Configuring portlet fragment caching
- After a portlet is invoked and completes generating the output
to cache, a cache entry is created containing the output and the side
effects of the portlet. These side effects can include calls to other
portlets or metadata about the entry, including timeout and entry
priority information.
- Eviction policies using the disk cache garbage collector
- The disk cache garbage collector is responsible for evicting objects
out of the disk cache, based on a specified eviction policy.
- Configuring the JAX-RPC Web services client cache
- The Web services client cache is a part of the dynamic cache service
that is used to increase the performance of Web services clients by
caching responses from remote Web services.
- Cache monitor
- Cache monitor is an installable Web application that provides
a real-time view of the current state of dynamic cache. You use it
to help verify that dynamic cache is operating as expected. The only
way to manipulate the data in the cache is by using the cache monitor.
It provides a GUI interface to manually change data.
- Invalidation listeners
- Invalidation listener mechanism uses Java events for alerting
applications when contents are removed from the cache.