+

Search Tips   |   Advanced Search

Configure dynamic cache (DynaCache) to use the WebSphere eXtreme Scale dynamic cache provider

The dynamic cache engine is the default cache provider for the dynamic cache APIs and framework. However, dynamic cache allows WebSphere eXtreme Scale (WXS) to act as its core caching engine. We can configure dynamic cache to use WXS as the cache provider instead of the default dynamic cache engine. Configuring dynamic cache to use WXS lets you leverage transactional support, improved scalability, high availability, and other WXS features without changing our existing dynamic cache caching code.

If we decide that is beneficial for the applications, use the information provided in the "Configuring the dynamic cache provider for WXS" section of the WebSphere eXtreme Scale v7.0 Product Overview to determine the appropriate WXS topology for our caching deployment.

If we use WXS, instead of the default dynamic cache engine, dynamic cache has the following limitations:


Enable the WebSphere eXtreme Scale dynamic cache provider

  1. Install the WXS client, or the WXS client and server packages on the application server for the remote server and the other topologies respectively.

    Only the WXS client installation, and the remote topology are supported.

  2. Designate the WXS dynamic cache provider as the cache provider.

    Each cache instance can be individually configured to use WXS. The dynamic cache engine is the default cache provider for a cache instance. Cache instances configured with WXS can coexist with cache instances configured with DRS.

    Complete one of the following actions to designate the WXS dynamic cache provider as the cache provider:

    1. Use the administrative console to designate the WXS dynamic cache provider as the cache provider.

      1. In the administrative console, click...

          Servers > Server Types > WebSphere application servers > server > Container Services > Dynamic cache service server

      2. In the Cache provider field, select WXS dynamic cache provider.

      3. Click OK.

    2. Add the cacheProviderName property to the cacheinstances.properties file that is bundled in an enterprise application, and set the property to...

        com.ibm.ws.objectgrid.dynacache.CacheProviderImpl

      For example, for cache.instance.26, we would add the following line to the cacheinstances.properties file:

        cache.instance.26.cacheProviderName = com.ibm.ws.objectgrid.dynacache.CacheProviderImpl

    3. Add the following Factory APIs to the code for an enterprise application:
      Properties p = new Properties();
                      ==>p.put(CacheConfig.CACHE_PROVIDER_NAME, CacheConfig.CACHE_PROVIDER_OBJECT_GRID);
                      DistributedMap map1 = DistributedMapFactory.getMap("myMap", p);
                      DistributedMap map2 = DistributedObjectCacheFactory.getMap("myMap2", p);
      

  3. Configure the replication setting for the cache instance.

    With the WXS dynamic cache provider we can have local cache instances, and replicated cache instances.

    If we are only going to use local cache instances, go to the last step, and save the configuration changes. In a local cache the WXS container is co-located with the JVM; that is, the WXS container and WAS share the same JVM heap.

    If we are going to use replicated caches, complete one of the following actions, depending on how we have created the cache instance:

    1. Go to...

      ...and set...

        com.ibm.ws.cache.CacheConfig.enableCacheReplication = true

    2. Add the enableCacheReplication property to the cacheinstances.properties file that is bundled in an enterprise application, and set the property to true.

      For example, for cache.instance.26, we would add the following line to the cacheinstances.properties file:

        cache.instance.26.enableCacheReplication = true

    3. Add the following Factory APIs to the code for an enterprise application:
      Properties p = new Properties();
                      p.put(CacheConfig.CACHE_PROVIDER_NAME, CacheConfig.CACHE_PROVIDER_OBJECT_GRID);
                      ==>p.put(CacheConfig.ENABLE_CACHE_REPLICATION, "true");
                      DistributedMap map1 = DistributedMapFactory.getMap("myMap", p);
                      DistributedMap map2 = DistributedObjectCacheFactory.getMap("myMap2", p);
      

  4. Configure the WXS replication topology.

    The only required configuration parameter for the WXS dynamic cache provider is the cache topology parameter.

    1. On the Java virtual machine > Custom properties page in the administrative console, click New again. In the Name field, enter...

        com.ibm.websphere.xs.dynacache.topology

      ...and one of the following values in the Value field:

      • embedded
      • embedded_partitioned
      • remote

      If we specify embedded_partitioned, we must also add the custom property...

        com.ibm.websphere.xs.dynacache.num_initial_containers

      ...to the JVM settings, and set this property to an integer that is equal to or slightly less than the total number of server instances that are accessing this distributed cache instance.

    2. Add the property....

        com.ibm.websphere.xs.dynacache.topology

      ...to the cacheinstances.properties file that is bundled in an enterprise application, and set the property to embedded, embedded_partitioned, or remote.

      For example, for cache.instance.26, we would add the following line to the cacheinstances.properties file:

        cache.instance.26.com.ibm.websphere.xs.dynacache.topology = embedded

      If we specify embedded_partitioned, we must also add the property...

        com.ibm.websphere.xs.dynacache.num_initial_containers property

      ...to the cacheinstances.propertiesfile, and set this property to an integer that is equal to or slightly less than the total number of server instances that are accessing this distributed cache instance.

      For example, if a dynamic cache service is shared between grid members, then the variable should be set to the number of grid members.

    3. Add the following Factory APIs to the code for an enterprise application:
      Properties p = new Properties();
                      p.put(CacheConfig.CACHE_PROVIDER_NAME, CacheConfig.CACHE_PROVIDER_OBJECT_GRID);
                      p.put(CacheConfig.ENABLE_CACHE_REPLICATION, "true");
                      ==>p.put("com.ibm.websphere.xs.dynacache.topology", "embedded");
                      ==>p.put("com.ibm.websphere.xs.dynacache.num_initial_containers", "3");
                      DistributedMap map1 = DistributedMapFactory.getMap("myMap", p);
                      DistributedMap map2 = DistributedObjectCacheFactory.getMap("myMap2", p);
      

    See the topic Configure the dynamic cache provider for WebSphere eXtreme Scale in the WebSphere eXtreme Scale v7 Information Center for more information about the embedded, embedded_partitioned, and remote settings.

  5. Configure the eXtreme Scale catalog service grid.

    When we run a catalog service grid, set the catalog.services.cluster custom property for the catalog service endpoints.

    See the topic Starting the catalog service process in a WAS environment in the WebSphere eXtreme Scale v7 Information Center for a description of how to start the catalog service process in a WAS environment.

    1. In the administrative console, click...

        System administration > Cell > Custom properties > New

    2. Enter catalog.services.cluster in the Name field, and the appropriate server:host_name:client_port:peer_port:listener_port value in the Value field.

      • server is the fully qualified name of the WebSphere process, such as the cell name, node name, or server name, of the server that hosts the catalog service. Example:

          cellA\node1\nodeagent

      • host_name is the name of the hosting server.

      • client_port is the port used for peer catalog grid communication.

      • peer_port is the port used for peer catalog grid communication.

      • listener_port is the listener port. This port must match the BOOTSTRAP_ADDRESS value defined in the server configuration.

      Following is an example of a valid value:

        cellA\node1\nodeagent:host.local.domain:6600:6601:2809,cellA\node2\nodeagent:host.foreign.domain:6600:6601:2809

    3. Click OK.

  6. Click Save to save all of the configuration changes.

  7. Restart all the application servers that we configured to use WXS.

  8. Configure custom key objects.

    When we are using custom objects as keys, the objects must implement the Serializable or Externalizable interface. If we are using custom objects with the embedded or embedded partitioned topologies, we must place the objects on the shared library path, in the same way that we do if we are using the default dynamic cache provider. For more information, see the topic Using the DistributedMap and DistributedObjectCache interfaces for the dynamic cache.

    If we are using the remote topology, we must place the custom key objects on the CLASSPATH for the stand-alone WXS containers. See the steps to start a container process in the WXS v7.0 Administration Guide for more information. This publication is available on the WXS library page

  9. Configure eXtreme Scale container servers.

    The cached data is stored in WXS containers. These containers can run inside or outside of a WAS process. The eXtreme Scale provider automatically creates containers inside a WAS process when we are using embedded or embedded partitioned topologies for a cache instance. No further configuration is needed for these topologies.

    When we use the remote topology, start up stand-alone eXtreme Scale containers before starting the WAS instances that access the cache instance. The WebSphere eXtreme Scale Version 7.0 Administration Guide documents the steps needed to complete to start stand-alone containers.

    Make sure that all the containers for a specific dynamic cache point to the same catalog service endpoints..

    The dynacache-remoteobjectgrid. xml and dynacache-remote-definition.xml configuration files for the stand-alone eXtreme Scale Dynamic Cache provider containers are located in the install_root/customLibraries/ ObjectGrid/dynacache/etc directory if WXS is installed on top of the WAS, or in the install_root/ObjectGrid/dynacache/etc directory if we are using a stand-alone version of WXS. Make copies of these files to edit and use when launching stand-alone containers for the eXtreme Scale dynamic cache provider. The value specified for the numIntitialContainers parameter in the dynacache-remote-deployment.xml file should be based on the number of container processes being run.

    The following example illustrates a UNIX-based command line entry that launches a stand-alone container for the WXS dynamic cache provider:

    startOgServer.sh container1 \
        -objectGridFile ../dynacache/etc/dynacache-remoteobjectgrid.xml \
        -deploymentPolicyFile ../dynacache/etc/dynacache-remotedeployment.xml \
        -catalogServiceEndpoints MyServer1.company.com:2809
    

    The set of container processes needs to have enough free memory to service all the dynamic cache instances configured to use the remote topology. Any WAS process that shares the same or equivalent values for catalog.services.cluster must use the same set of stand-alone containers. The number of containers and number of machines they reside on needs to be sized appropriately. See the topic Capacity planning and high availability in the WebSphere eXtreme Scale v7.0 Product Overview for additional details. This publication is available on the WXS library page.

  10. Verify that the WXS dynamic cache provider is correctly configured.

    If the WXS dynamic cache provider is correctly configured, the system log contains a number of messages similar to the following messages:

      DYNA1001I: WebSphere Dynamic cache instance named "{0}" initialized successfully using cache provider "{1}".
      DYNA1071I: The cache provider \"{0}\" is being used.

    If the configuration and initialization of the cache instance with WXS fails the dynamic cache runtime reverts to the default dynamic cache cache provider, and we should see messages similar to the following message in the system log.

      DYNA1066E: Unable to initialize the cache provider \"{0}\". The Dynamic cache will be used to create the cache instance \"{1}\" instead of the configured cache provider.


Subtopics


Related:

  • Introduction: Dynamic cache
  • Use the DistributedMap and DistributedObjectCache interfaces for the dynamic cache
  • WebSphere eXtreme Scale library page
  • WebSphere eXtreme Scale examples