Configuring the embedded global cache

By default, the global cache is turned off, and the cache policy is set to disabled. To use the global cache, select an integration node-level cache policy by using the cachePolicy parameter. The global cache has a default single-integration node topology that can be used immediately without any configuration. To use the default topology, change the cache policy property to default. The integration node sets a range of ports to use, but you can specify a particular range of ports. You can also specify the listener host that is used by the integration node 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.

When you use the default topology, integration server properties are read only; an error is issued if you try to change them. You can switch off the default topology by selecting an integration node cache policy of none, and 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 integration node performance. The integration server properties that were set most recently by the integration node-level policy are retained as a starting point for customization.

To disable all cache components in the integration node, set the cache policy property to disabled. Integration server properties are removed and cannot be changed. When the cache is enabled, the memory usage of integration servers that host cache components is larger. If this memory usage is an issue, and you do not need to use the global cache, set the cache policy property to disabled.

If you stop the integration server that contains the catalog server, the cache becomes unavailable. 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 integration node to reset all cache components.

For more information, see Configuring the embedded global cache by using commands. You can also configure the embedded global cache by using the IBM Integration API. The cache manager properties are documented in the Javadoc for the IBM Integration API (see IBM Integration API.)

You can configure the global cache to span multiple integration nodes by providing an XML policy file. This policy file lists the integration nodes that share the cache, and for each integration node specifies the listener host, port range, and the number of catalog servers hosted. You can use the policy file to set up a single integration node that hosts two catalog servers. If one catalog server is lost, the integration node switches to the other catalog server, ensuring that no cache data is lost. For more information, see Configuring the global cache for multiple integration nodes.

You can also use the policy file to configure a multi-instance integration node to host more than one container server. If the active instance of the multi-instance integration node fails, the global cache switches to the container server in the standby instance. For more information, see Configuring the global cache for multi-instance integration nodes.

Depending on the type of data you store in your cache, you can configure your embedded global cache to use different locking strategies, and you can configure the use of replica shards for read access. For more information, see Optimizing the embedded global cache for use with different types of cache data.