See information about the latest product version
Data caching terminology
The global cache is embedded in the broker. You can also connect to an external WebSphere® eXtreme Scale grid.
The embedded cache has a default single-broker topology and can be used by message flows running in any execution group on the broker, without any configuration. However, you can switch off the default topology by selecting a broker policy of none, and set properties explicitly for each execution group.
The following diagram shows the embedded global cache in a broker that contains six execution groups. Four execution groups host components for the global cache, but message flows in all six execution groups can use the cache.

The following diagram shows a multi-broker embedded cache, which is configured by the broker policy file policy_two_brokers_ha.xml.

The following diagram shows how WebSphere Message Broker can connect to both an embedded cache and an external WebSphere eXtreme Scale grid. A configurable service is used to connect to the external grid.

- Broker-level properties
- By default, the global cache is turned off, and the cache policy
is set to disabled. To use the global cache, select
a broker-level cache policy by using the cachePolicy parameter.
WebSphere Message Broker has a default cache policy that creates a default topology of cache components in a single broker. The default topology puts catalog servers and container servers in execution groups dynamically so that the cache is available for use by all execution groups in the broker. Broker-level properties are available to specify a range of ports, and a listener host for the default topology. The broker sets a range of ports to use, but you can specify a particular range of ports by using the cachePortRange parameter. You can use the listenerHost parameter to specify the listener host that is used by the cache components. If your computer has more than one host name, setting the listener host ensures that the cache components use the correct host name.
If you set the cache policy to none, you must set the execution group properties explicitly. The properties that were set most recently by the broker-level policy are used as a starting point. Therefore, if you set the cache policy to default first, then switch to none, the default topology properties are retained.
You can configure the global cache to span multiple brokers by setting the cache policy to the fully qualified name of an XML policy file. This policy file lists the brokers that share the cache, and for each broker specifies the listener host, port range, and the number of catalog servers hosted. You can use the policy file to set up a single broker that hosts two catalog servers. If one catalog server is stopped, the broker switches to the other catalog server, ensuring that no cache data is lost.
If you set the cache policy to disabled, all cache components in the broker are disabled. The disabled policy is the default setting.
For more information, see Configuring the embedded global cache and Parameter values for the cachemanager component.
- Cache manager
- The cache manager is the execution group resource that manages
the cache components that are embedded in that execution group.
In the default topology, one execution group in the broker hosts a catalog server, and up to three other execution groups in that broker host container servers. All execution groups can communicate with the global cache, regardless of whether they are hosting catalog servers, container servers, or neither. Each execution group contains a cache manager, which manages the cache components that are embedded in that execution group. When you turn off the default topology, configure the execution groups by setting the parameter values for the cachemanager component.
For more information, see Configuring the embedded global cache and Parameter values for the cachemanager component.
- Container servers
- A container server is a component that is embedded in the execution group that holds a subset of the cache data. Between them, all container servers in the global cache host all of the cache data at least once. If more than one container exists, the default cache policy ensures that all data is replicated at least once. In this way, the global cache can cope with the loss of container servers without losing data.
- Catalog servers
- The catalog server controls placement of data and monitors the
health of containers. You must have at least one catalog server in
your global cache.
To avoid losing cache data when a catalog server is lost, use a policy file to specify more than one catalog server for a broker. For example, if you specify two catalog servers for a single broker, if one catalog server fails, the broker switches to the other catalog server. If the cache is shared by two brokers, each of which hosts a catalog server, if one catalog server fails, the brokers switch to the remaining catalog server. Having more than one catalog server can affect startup time until the cache is available. If you have more than one catalog server, you must start at least two of them for the cache to be available. When you configure a cache across multiple brokers with multiple catalog servers, if you need to start one broker before the others then you can configure this broker to host two catalog servers.
When you are using multiple catalog servers, you can improve performance by taking the following steps:- Provide other execution groups that host container servers only, rather than having only execution groups that host both catalog and container servers.
- Start and stop execution groups in sequence, rather than using the mqsistart or mqsistop commands to start or stop all execution groups at once. For example, start the execution groups that host catalog servers before you start the execution groups that host only container servers.
- Domain name
- When you are using a global cache that spans multiple brokers,
ensure that all WebSphere eXtreme
Scale servers
that are clustered in one embedded grid use the same domain name.
Only servers with the same domain name can participate in the same
grid. WebSphere eXtreme
Scale clients use the domain
name to identify and distinguish between embedded grids. If you do
not specify a domain name in the execution group or broker-level policy
file, the broker creates a name that is based on the server names
of the catalog servers.
By default, each server starts with a domain name that is derived by the broker. In previous versions of WebSphere Message Broker, the domain name for all WebSphere eXtreme Scale servers in all embedded caches was an empty string. Servers in different domains cannot collaborate in the same grid. Therefore, for a cache that spans more than one broker, migrate those brokers at the same time.
- Grids
- WebSphere eXtreme Scale provides a scalable, in-memory data grid. The data grid dynamically caches, partitions, replicates, and manages data across multiple servers. The catalog servers and container servers for the WebSphere Message Broker global cache collaborate to act as a WebSphere eXtreme Scale grid. For more information about grids, see WebSphere eXtreme Scale information center.
- Maps
- Data is stored in maps. A map is a data structure that maps keys
to values. One map is the default map, but the global cache can have
several maps.
The cache uses WebSphere eXtreme Scale dynamic maps. Any map name is allowed, apart from names that begin with SYSTEM.BROKER, which is reserved for use by the broker. The default map is named SYSTEM.BROKER.DEFAULTMAP; you can use or clear this map.
- ObjectGrid file
- An ObjectGrid XML file is used to configure the WebSphere eXtreme Scale client. You can use this file to override WebSphere eXtreme Scale properties. For more information about configuring clients, see WebSphere eXtreme Scale information center.
- WebSphere Message Broker commands (see Configuring the embedded global cache by using commands)
- WebSphere Message Broker Explorer (see Configuring the embedded global cache by using WebSphere Message Broker Explorer)
- An XML policy file (see Configuring the global cache for multiple brokers)
- Message Broker API (see Configuring the embedded global cache)
- Execution group properties (see Parameter values for the cachemanager component)
- Configurable services (see Connecting to a WebSphere eXtreme Scale grid)
You can use resource statistics and activity trace to monitor the status of the global cache and external grid, and to diagnose problems. You can also administer the embedded global cache by using the mqsicacheadmin command.