Migrating from the embedded WebSphere eXtreme Scale (WXS) grid to the embedded global cache

Starting in IBM® App Connect Enterprise version 13.0.3.0, the embedded WXS grid (based on Java™ 8) is deprecated. For new implementations, use the embedded global cache instead of the embedded WXS grid. Migrate existing configurations to the embedded global cache to prepare for the future removal of the embedded WXS grid. For more information about choosing the right type of cache, see Choosing the right type of cache.

Note: If you need more active control over the cache administration, consider using the external Redis global cache instead of the embedded global cache. To migrate to the external Redis global cache, see Migrating from the external WebSphere eXtreme Scale (WXS) grid to the external Redis global cache.

To migrate from the embedded WXS grid to the embedded global cache, update your configuration as described in Configuring the embedded global cache. In addition, update any use of the mqsicacheadmin command to use the equivalent ibmint display cache command and ibmint clear cache command as described in Administration of the embedded global cache.

The way that you use the global cache within a flow remains mostly the same. Flows that previously worked with the embedded WXS grid should also function with the embedded global cache, if your configuration and administration have been updated. There is no need for flow migration or changes in development, but take note of the flow development behaviors that are mentioned in the following sections.

Behavioral considerations

Migrating to and using the embedded global cache is made as straightforward as possible. Be aware of the following behavioral considerations that you may encounter during the migration process or when developing with the embedded global cache.

Replication behavior

The embedded global cache uses a simpler architecture than the embedded WXS grid. When configuring replication, consider the following behaviors:

Requests arriving through the listener don’t propagate

Only values that are written by a server's own message flows have their values replicated to that server's write list. For example, if a value is sent to 'Server 4' through its listener from another server, that value will not be added to 'Server 4's write list.

Similarly, only values being read by a server's own message flows will be requested from the replicatedReadsFrom servers if they are not found locally. If a read request comes to 'Server 4's listener and 'Server 4' does not have the value found locally, it will not propagate the read request to 'Server 4's read list.

Replication failure is not a flow failure

Requests to replicate a write are asynchronous, and any failure will not affect your flow. Similarly, if a request to replicate a read fails, it is considered as if the value was not found on that server.

Cache consistency

Unlike the embedded WXS grid, the embedded global cache takes a simpler method for maintaining cache consistency.

For example, in the following image, if Server 1 inserts the key “foo” with the value “blah” into a map, that key and value will get replicated to Server 2. However, if Server 2 then has its own message flow overwrite the key “foo” with a new value, “baz”, Server 1 will not receive any updates about this change. Therefore, if you require a consistent cache across multiple servers, it is necessary that all servers read from and write to each other, or to a common server (or a set of servers).

Example of a cache configuration with three servers

Flow development behaviors

When configuring the flow, consider the following behaviors:

Thread behavior with MbGlobalMapSessionPolicy

The thread behavior using the MbGlobalMapSessionPolicy, which specifies the Time To Live (TTL) for values in that map, has changed. Most users are expected to find the new behavior more intuitive.

When using the embedded WXS grid, the last TTL value set while creating an MbGlobalMap on a specific thread applies to all MbGlobalMaps on that thread. For example:

MbGlobalMap map1 = MbGlobalMap.getGlobalMap("My.Map"lo, new MbGbalMapSessionPolicy(10));
map1.put("key1", "value"); // entry has a 10 second TTL

MbGlobalMap map2 = MbGlobalMap.getGlobalMap("My.Map", new MbGlobalMapSessionPolicy(20));

// Don't use map2, but it sets the TTL on the thread local handle

// Note, reusing the same map handle will use the last TTL value that was last set on this thread
map1.put("key2", "value"); // entry has a 20 second TTL(!)

MbGlobalMap map3 = MbGlobalMap.getGlobalMap("My.Map");
map3.put("key3", "value"); // entry also has a 20 second TTL

With the new embedded global cache, the TTL is specific to the map handle. For example:

MbGlobalMap map1 = MbGlobalMap.getGlobalMap("My.Map", new MbGlobalMapSessionPolicy(10));
map1.put("key1", "value"); // entry has a 10 second TTL

MbGlobalMap map2 = MbGlobalMap.getGlobalMap("My.Map", new MbGlobalMapSessionPolicy(20));

// Note, reusing the same map handle will use the handle specific TTL
map1.put("key2", "value"); // entry has a 10 second TTL

MbGlobalMap map3 = MbGlobalMap.getGlobalMap("My.Map");
map3.put("key3", "value"); // entry has no TTL

Getting a MbGlobalMap with a connection policy name

When you get a map within a flow, you have the option to specify a policy name. In earlier versions of App Connect Enterprise, this could only be a WXS Server policy to connect to an external WXS grid. However, from App Connect Enterprise version 13.0.3, you can now also use a Redis Connection policy to connect to an external Redis server. Choosing either of these options overrides the default cache type and establish a connection to the specified cache type.

The default map type when getting a MbGlobalMap without a connection policy name

When you get a global map without specifying a policy name, you receive a map of the default cache type for that server. As of App Connect Enterprise version 13.0.3, the default cache type is determined based on the following criteria when the server starts up:

The default cache type starts as the embedded global cache.
If you have the now deprecated cacheOn: true property set in the GlobalCache ResourceManager section of your server.conf.yaml file, the default cache type is overridden to the embedded WXS grid.
If you have the now deprecated defaultCacheType: property set to global (for WXS) or local, your default cache type is overridden to embedded WXS grid or local respectively.
If you have the environment variable MQSI_GLOBAL_CACHE_USE_LOCAL_CACHE set in the integration server's environment, the default cache type is overridden to local.