We know by Storing the active data in a close-by location like "in-memory", we can reduce the number of trips to either databases or file systems or any other over the network resources. This sometimes saves not only the performance hitches, but is also economically viable if one has to pay per request service. The need for enterprise level global caching is catching up fast, with the invasion of "smart" tools into our daily lives and the increase in expectations for "highly available(HA)" large volumes of secure data be made ready for manipulations, in the shortest span of time. Data caching is now an established middleware concept that makes the applications feel more responsive to its clients. Using IBM WebSphere eXtreme Scale (WXS) product, one can dynamically cache the data across multiple servers forming an "in-memory" data grid.
From v8 (fixpack 1) onwards, WebSphere Message Broker (WMB) started packaging some of the Websphere eXtreme Scale APIs. By this broker JVMs (execution group, EG) can be logically tied together for extreme (massive volumes) transactional data processing with transactional integrity, high availability and predictable reduced response time. Global Caching can now be formed by the distributed caching among JVMs in a single or multiple message brokers. With the default policy, the cache is distributed across all the execution groups. The size of the cache is purely dependant upon the data that gets into it and the available JVM heap size across the EGs. Usually when a broker is enabled for global caching, it can be noticed that there is slight increase in the minimum JVM HeapSize to accommodate basic catalogs. At the moment there are some limitations on the type of objects that can be put to this caching. Also WXS will ensure there are two copies of data stored in the cache across the containers. The life of the data that can stay in the cache can be defined from FP02 onwards.
Also WMB v8 FP02 comes with v220.127.116.11 WXS. So the broker can be effectively configured to act as a "client" for connecting to external WXS grids like DataPower XC10 or embedded WXS servers in WebSphere Application Server (WAS) or a stand-alone WXS grid. The global cache is embedded in the broker. You can also connect to an external WebSphere eXtreme Scale grid.
By default the global cache is turned off and the CacheManager's cache policy is disabled at the broker level. Using mqsichangebroker command one can turn this feature on.
As you can see from the following output of the commands, there two types of properties. The Cachepolicy and the policy file, the port range, and listener host properties are to be defined at broker level. While the catalog, container JMX, and SSL services have to be configured at the Execution group level due to the obvious reasons.
>mqsireportproperties MB8BROKER -b cachemanager -o CacheManager -r
BIP8071I: Successful command completion.
#mqsireportproperties MB8BROKER -e GlobalCache1 -o ComIbmCacheManager -r
BIP8071I: Successful command completion.
For complete details on how one can enable and configure cache policy, see section "Configuring the embedded global cache" in the information center.
By default there will be one Catalog server and up to four container servers can be created in a message broker. There are no limitations on the number of brokers that can participate in the global caching. The catalog server controls placement of data and also monitors the health of containers.
One can access global cache using MBGlobalMap object in Java™ compute node or by calling the Java static methods in ESQL. See "Accessing the global cache with a JavaCompute node" in the information center for details.
There are a few recent APARs dealing with cache that you should have applied:
IC84962: GLOBAL CACHE SUPPORT FOR WEBSPHERE MESSAGE BROKER V8.0
IC87324: Caching of Parent and Global Transaction IDS
IC88062: GLOBAL CACHE CAN LOSE DATA WHEN MACHINE FAILS IN ACTIVE/ACTIVE HA
IC91435: INCORRECT DEFAULT GLOBALCACHE PROPERTIES WITH 'NONE' POLICY
You can always check for the latest fixes in document "Fix list for WebSphere Message Broker Version 8.0"
or on our WebSphere Message Broker support page.
Additional reference: Introduction to the WebSphere Message Broker global cache