Related concepts:
Related tasks:
Use the global cache that is supplied with IBM® Integration Bus 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 integration servers, or to use an XML policy file to enable the cache across multiple brokers.
To find out more about the differences between the embedded cache and the external grid, see Differences between the embedded global cache and an external WebSphere eXtreme Scale grid.
By default, one integration server 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 integration servers in that broker host container servers. A container server is a component that is embedded in the integration server that holds a subset of the cache data. The catalog server and container servers are placed in integration servers dynamically when the broker starts. All integration servers can communicate with the global cache, regardless of whether they are hosting catalog servers, container servers, or neither. Each integration server contains a cache manager, which manages the cache components that are embedded in that integration server. For a description of the cache components, see Data caching terminology.
When you use the default topology, the cache properties for individual integration servers 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 integration server, you must first change the cache policy property to none. The integration server properties that were set most recently by the broker-level policy are retained as a starting point for customization.
You can set properties explicitly for each integration server. For example, you might want to specify particular integration servers 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 integration server uses the values that you set. The integration server properties that were set most recently by the broker-level policy are retained as a starting point for customization.
If you stop the integration server 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 integration server that hosts the catalog server, it can no longer communicate with the container servers in other integration servers. 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 integration servers that host the container servers. Alternatively, restart the broker to reset all cache components.
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 integration server 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 IBM Integration Bus, 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 IBM Integration Bus commands, IBM Integration Explorer, or the IBM Integration 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.
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. You can use your own Java™ classes with the global cache. To use your own Java classes, put the JAR files that contain the Java classes in the shared classes directory at system level, broker level, or integration server level. You must make the Java classes available to all brokers and integration servers that participate in the global cache. 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, integration servers, 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.
Last updated Friday, 21 July 2017
