[Fix Pack 29 or later]


Dynamic cache service multi-cell and multi-core group invalidation

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 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.

Invalidation information flow in a dynamic cache service multi-cell and multi-core group environment

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:

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:
  1. 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.
  2. Configuration of the Outbound JMS/service integration bus, which consists of configuring the JMS queue connection factory.
  3. 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.



Related concepts
Enabling the dynamic cache service
Related tasks
Enabling dynamic cache service multi-cell and multi-core group invalidation with scripting
Related reference
Java virtual machine custom properties
Concept topic Concept topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 4:28:44 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-mp&topic=cdyn_multicell
File name: cdyn_multicell.html