DynaCache Cache Replication with WebSphere Process Server and ESB

As I blogged about previously, there is a useful technique which involves inserting Java components into SCA modules to cache the results of services using the DynaCache mechanism of WebSphere Application Server. See Gabriel Telerman’s excellent article for more information.

However, if you deploy applications using this technique across a WebSphere cluster, which is fairly typical of a production WebSphere environment, you’ll most likely want to look into WebSphere cache replication (using DRS – the data replication service). This means that rather than having an independent caches on each cluster member (i.e. each server), you’ll have caches that replicate data between each other when it is invalidated or updated in the cache.

This is documented in detail towards the bottom of this InfoCenter page, but broadly speaking you’ll want to modify the properties of the object cache you’re already using. In the article referenced above, the default cache services/cache/distributedmap is used, but to extend this with replication across a cluster, it’s probably appropriate to create your own object cache first if you haven’t already. You then need to specify a “replication domain” for that cache (you’ll need to create one if you don’t already have one), and the replication type. Often “Push only” is suitable for most performance requirements – this pushes new cache entries across the cluster when they are created, modified, or invalidated.

Some other points to be aware of:

• The Data Replication Service doesn’t always start up straight away on server startup – sometimes it will take a few minutes.
• It’s primarily intended for internal IBM use, but you may find that the tracing string com.ibm.ws.cache.*=all is useful for figuring out what’s going on inside the cache if it’s not behaving as you expect. It will show cache hits, misses, and replication.