Embedded global cache

Use the global cache that is supplied with IBM® App Connect Enterprise to store data that you want to reuse.

The global cache is embedded in IBM App Connect Enterprise, and is disabled by default. To use the cache, you must enable and configure it by setting properties in the server.conf.yaml files for the integration servers that will share access to the cache.

The embedded global cache in IBM App Connect Enterprise can use a WebSphere® eXtreme Scale enterprise data grid. Enterprise data grids use the eXtreme data format (XDF) instead of Java™ object serialization. XDF allows for class evolution, which means that you can evolve the class definitions that are used in the data grid without affecting older applications that are using previous versions of the class. For more information, see Enterprise data grid overview in the WebSphere eXtreme Scale product documentation.

Note: The App Connect Enterprise global cache is implemented using WebSphere eXtreme Scale technology. WebSphere eXtreme Scale is designed to offer a resilient cache topology by hosting a known number of catalog and container servers in a fixed topology. This is not compatible with the ephemeral nature of containers running in elastically-scaled cloud environments such as Kubernetes. Therefore, WebSphere eXtreme Scale does not support running the catalog or container server components in containerized environments such as Kubernetes, Docker, or Podman. As a result, App Connect Enterprise does not support the embedded global cache when running an integration server in a containerized environment. The embedded global cache is supported to make a client connection to an external WebSphere eXtreme Scale grid when running in a container.

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.

Customizing the embedded topology

You can set properties explicitly for each integration server, by setting properties in each server.conf.yaml configuration file. For example, you might want to specify particular integration servers to host the catalog and container servers so that you can tune performance.

If you stop the integration server that contains the catalog server, the cache becomes unavailable and the data in the cache is lost. Therefore, you must ensure that you define 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.

When you use multiple catalog servers, you can improve performance by taking the following steps:
  • Provide other integration servers that host container servers only, rather than having only integration servers that host both catalog and container servers.
  • Start and stop integration servers in sequence, rather than using the mqsistart or mqsistop commands to start or stop all integration servers at once. For example, start the integration servers that host catalog servers before you start the integration servers that host only container servers.

You can configure the global cache by using IBM App Connect Enterprise commands, or the IBM Integration API.

For more information, see Configuring the embedded global cache.

Interaction with the global cache

You can use Mapping nodes or 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 by using a Mapping node or Accessing the global cache by using 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 or integration servers, 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 Specifying how long data remains in the global cache by using the JavaCompute node.

Using the embedded local cache

The embedded local cache can be configured for use in IBM App Connect Enterprise. You can also configure the embedded local cache to allow flows that contain cache lookups to run within containerized environments, which do not support the embedded global cache. This capability is available in version 12.0.4.0 onwards.

When using the embedded local cache, a Java HashMap is used as the underlying storage for the map instead of a WebSphere eXtreme Scale grid, which means the embedded local cache is scoped to a single integration server. Each integration server will have its own in-memory copy of the cache, and updates made in one integration server will not be reflected in other integration servers. Cache transactions are also not supported when using the embedded local cache.

The embedded local cache is API compatible with the embedded global cache. This means that message flows will continue to work as designed when switching between the local and global variants of the cache.

To configure an integration server to use the embedded local cache instead of the embedded global cache, set the defaultCacheType property in the server.conf.yaml file as follows:

GlobalCache:
   defaultCacheType: 'local'
Note: The cacheOn property in the server.conf.yaml file controls whether to start up the WebSphere eXtreme Scale resources, which are used to implement the catalog and container server components of the embedded global cache. If the embedded local cache is the only caching mechanism in use, set the cacheOn property to false.

To support use cases where the embedded global cache can be used alongside the embedded local cache, the MbLocalMap class is provided to implement the same interface as MbGlobalMap.