Configuring Cache replication

You can configure DynaCache so that, Data replication service will replicate data across all the servers in a replication domain, i.e. you can configure it so that if Server 1 creates a cache entry that gets copied to all other servers in say that cluster and other clusters wont have to create that entry explicitly. Invalidations of cache entries are sent across the cluster to keep the cached data consistent and valid.

Follow these steps to configure dynamic caching service replication for all the servers in particular cluster

  • Before you configure the DynaCache replication, make sure that you already have a replication domain. You can either create the replication domain as part of cluster creation process or manually

  • Go to WAS Admin Console and for each of the servers in the cluster go to Servers -> Application Servers -> server_name -> Container Services -> Dynamic Cache service

    On this page Check "Enable Cache Replication" checkbox and then set following values

    • Full group replication domain: Use different replication domains for each type of consumer. For example, dynamic cache should use a different replication domain than session manager. The only replication domains that you can select in this panel include replication domains that are configured to use full-group replication. In a full-group configuration, every cache entry is replicated to every other cache that is configured in the servers that are in the replication domain. If none of the replication domains in your configuration meet these requirements, the list is empty. In this case, create a replication domain or alter an existing replication domain so that you have a replication domain that can perform full-group replication.

    • Replication Type: Select appropriate replication type where

      • Not Shared: Cache entries for this object are not shared among different application servers. These entries can contain non-serializable data. For example, a cached servlet can place non-serializable objects into the request attributes, if the class type supports it.

      • PUSH: Cache entries for this object are automatically distributed to the dynamic caches in other application servers or cooperating Java Virtual Machines (JVMs). Each cache has a copy of the entry at the time it is created. These entries cannot store non-serializable data.

      • PULL:Cache entries for this object are shared between application servers on demand. If an application server gets a cache miss for this object, it queries the cooperating application servers to see if they have the object. If no application server has a cached copy of the object, the original application server runs the request and generates the object. These entries cannot store non-serializable data. This mode of sharing is not recommended.

      • PUSH_PULL: Cache entries for this object are shared between application servers on demand. When an application server generates a cache entry, it broadcasts the cache ID of the created entry to all cooperating application servers. Each server then knows whether an entry exists for any given cache ID. On a given request for that entry, the application server knows whether to generate the entry or pull it from somewhere else. These entries cannot store non-serializable data.

    • Push Frequency: you can define when and how often data is replicated across the dynamic cache replication domain

1 comment:

Technology said...

Hi Sunil,

I have small doubt on ibm http .We have done some modification on http.conf file.So we want view modified data before or after restart webserver.So how to view whole syntax of data modified before and after webserver?.
Note: Don't use the diff/vi/cat command.