Dynamic cache service multi-cell and multi-core group invalidation
enables caches created in different cells to be synchronized without
the cache entries being replicated across cell boundaries. When this
function is enabled, data gets cached in both cells as a result of
the cells handling the same traffic. When a cache entry is invalidated,
using the Java Message Service (JMS), the ID of the invalidated cache
entry is sent to a peer cell. The receiving cell uses a service integration
bus to process the invalidation. This function can also be used to
propagate invalidations to other core groups in the same cell.
Avoid trouble: Dynamic cache service multi-cell
and multi-core group invalidation is only available for servlet cache
instances.
gotcha
The dynamic cache external cache adapter, ExternalCacheAdapter
(ECA), is used to capture invalidations from a server. JMS/service
integration bus is used to send and receive invalidations in the remote
cell or core group. Additional application servers are created to
host the invalidation application. These servers automatically become
members of the service integration bus. These application servers
process the invalidations, which consist of JMS messages, from the
remote cell and communicate them to the cluster members in the local
cell.
The external cache adapter, com.ibm.websphere.servlet.cache.RemoteInvalidator,
is used to send the IDs of invalidated caches to a service integration
bus in a remote cell. Instead of specifying a host:port for the
address, this type of external cache adapter uses the JMS queue connection
factory JNDI name, and queue destination name of the remote service
integration bus as the address:
Adapter bean name = com.ibm.websphere.servlet.cache.RemoteInvalidator
Address = JMS_QUEUE_CONNECTION_FACTORY_JNDI_NAME, REMOTE_QUEUE_DESTINATION_NAME
Before you can use this function, you must ensure that:
- Each cell or core group contains a cluster that is hosting a production
application. The same production application has to be used in both
cells or core groups to ensure invalidation IDs are processed correctly.
- A separate cluster of two servers is created in each cell or core
group to host the service integration bus. The members of this cluster
cannot have a RemoteJMSInvalidator external cache group defined. If
a RemoteJMSInvalidator external cache group is defined for these cluster
members, an infinite loopback condition occurs where invalidations
are repeatedly send back and forth between cells.
- A datasource is defined and is accessible from both service integration
bus cluster members. If the database is shared by both cells, ensure
a unique database name is used when defining each the datasource for
each cell.
- Each cell or core group contains a replication domain that contains
both the service integration bus cluster and all of the clusters hosting
the production applications.
Configuration considerations
The dynacacheJMSSIB.py
script is provided in the
WAS_INSTALL_ROOT/util/
directory. Use this script to configure the external cache adapter
and service integration bus infrastructure in both cells. The script
must be executed from the
WAS_INSTALL_ROOT/profiles/PROFILE_NAME/bin
directory for it to work correctly. For example:
WAS_INSTALL_ROOT/profiles/Dmgr01/bin)
The
configuration of the servlet cache instances should be available to
both clusters in a core group. You can use either a properties file,
a factory or the administrative console to configure a servlet cache
instance. This configuration must be set at the cell scope, and must
be available to both the service integration bus and production clusters
in the core group. The easiest way to ensure this availability is
to create and define the cache instances on both the Web production
and the service integration bus clusters when you install the application.
The
dynacacheJMSSIB.py script configures each cell in 3 steps:
- Configuration of the Inbound JMS/service integration bus, which
consists of the following actions:
- The creation of a service integration bus and the specification
of a service integration bus destination.
- The creation of the JMS queue.
- The activating the JMS.
- Installation of the WAS_INSTALL_ROOT/installables/DynacacheMessageHandler.ear
file, which is a message driven bean, on the service integration bus
cluster.
- Configuration of the Outbound JMS/service integration bus, which
consists of configuring the JMS queue connection factory.
- Configuration of the external cache group, which consists of configuring
the external cache group, and external cache adapter on each cluster
member that is hosting the production applications.
Tuning considerations
The following Java
virtual machine (JVM) custom properties are can be used to tune the
dynamic cache service multi-cell and multi-core group invalidation:
- dynacache.jms.connRetryInterval
- Specifies the number of seconds that a cluster member waits before
attempting to reconnect to a service integration bus server. The
default value is 30
- dynacache.jms.numStoredInvalidations
- Specifies the maximum number of invalidation IDs a cluster member
can store while waiting for a service integration bus server to become
available. After the threshold is reached, the oldest invalidations
is removed. The default value is 10000.
- dynacache.jms.cacheInstance
- Specifies the cache instance to use for processing invalidations.
Setting this property to "*" causes invalidation IDs to be processed
on all cache instances. By default, the baseCache cache instance
is used. This property is only applicable to the service integration
bus servers.
- dynacache.jms.invProcessingDelay
- Specifies the number of seconds the service integration bus server
queues invalidation IDs before processing them. The default value
is 20.