See information about the latest product version
Embedded global cache
Use the global cache that is supplied with WebSphere® Message Broker to store data that you want to reuse.
The global cache is embedded in the broker. By default, the cache is disabled; to use the cache, select an appropriate cache policy. The default cache policy creates a default topology of cache components in a single broker. The alternatives to the default topology are to have no policy, so that you can control your own topology by setting cache properties on the execution groups, or to use an XML policy file to enable the cache across multiple brokers.
The default topology
By default, one execution group in the broker hosts a catalog server. The catalog server controls placement of data and monitors the health of container servers. Up to three other execution groups in that broker host container servers. A container server is a component that is embedded in the execution group that holds a subset of the cache data. The catalog server and container servers are placed in execution groups dynamically when the broker starts. 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. For a description of the cache components, see Data caching terminology.
- The first execution group to start is a catalog server and a container server. This execution group uses the first four ports from the range.
- The second execution group to start is a container server only; it uses the three ports in the range (ports 5 - 7).
- The third and fourth execution groups to start are container servers only, and use ports 8 - 10 and 11 - 13 from the range.
- If further execution group are started, they do not host global cache components. However, all execution groups can communicate with the global cache as clients.
- If you stop the execution group that contains the catalog server, the global cache becomes unavailable.
- If you stop the second, third, or fourth execution group, the container server of the stopped execution group is assigned to the next execution group that starts.
When you use the default topology, the cache properties for individual execution groups are read only; an error is issued if you try to change them. When you use the default topology, you can specify the range of ports that the cache manager uses, and 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. To set specific properties for the execution group, you must first change the cache policy property to none. The execution group properties that were set most recently by the broker-level policy are retained as a starting point for customization.
Multi-broker cache topologies
- A single broker that hosts two catalog servers; if one catalog server fails, the global cache switches to the other one.
- Two brokers that share a catalog server that is hosted by the first broker.
- Two brokers that each host a catalog server; if one catalog server fails, the global cache switches to the catalog server in the other broker.
Customizing the embedded topology
You can set properties explicitly for each execution group. For example, you might want to specify particular execution groups to host the catalog and container servers so that you can tune broker performance. When the cache policy is set to none, the cache manager in each execution group uses the values that you set. The execution group properties that were set most recently by the broker-level policy are retained as a starting point for customization.
If you stop the execution group that contains the catalog server, the cache becomes unavailable and the data in the cache is lost. Therefore, if you switch off the default topology, ensure that you place the catalog server appropriately. If you restart the execution group that hosts the catalog server, it can no longer communicate with the container servers in other execution groups. Although these container servers are still running, they are no longer part of the cache, and your data is lost. Therefore, you must also restart the execution groups that host the container servers. Alternatively, restart the broker to reset all cache components.
- 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.
When you use 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 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 multiple brokers, migrate these brokers at the same time.
You can configure the global cache by using WebSphere Message Broker commands, WebSphere Message Broker Explorer, or the Message Broker API. For more information, see Configuring the embedded global cache.
You can disable all cache components in the broker by setting the cache policy property to disabled. The cache policy is set to disabled by default.
Interaction with the global cache
You can use JavaCompute nodes to store and retrieve data in a map in the global cache. When you get a global map from an external grid, the getGlobalMap method makes a connection to the grid if one does not exist. For more information, see Accessing the global cache with a JavaCompute node.
When you get an MbGlobalMap object, you can also specify how long the data remains in the global cache before it is removed automatically. This time is known as the time to live and is counted from when that map entry is last updated. The value applies to all cache entries that are created by using that MbGlobalMap object in that instance of the message flow. Data that is already in the map that you specify, or that is created by another MbGlobalMap object, is not affected by the time to live value. You can create multiple MbGlobalMap objects in different flows, execution groups, or brokers, all resolving to the same map in the global cache, but with different time to live values.
By default, the time to live is set to zero so that the data is never removed. To set a specific time to live, create a session policy, which you can reference from the MbGlobalMap object. For detailed instructions, see Removing data from the global cache.