Administration guide > Configure the deployment environment > Configuring cache integration


Configure the dynamic cache provider for WebSphere eXtreme Scale

Overview

To use the dynamic cache provider, WXS must be installed on top of WAS node deployments, including the deployment manager node.

If catalog servers within the catalog service domain have SSL enabled, global security must be enabled using the WAS administrative console. To require SSL for a catalog server set transportType attribute to SSL-Required in the Server properties file.

See also:

  1. Enable the dynamic cache service and servlet caching
  2. Enable WebSphere Commerce data cache

If you are not specifically directing the caching to a defined Object Cache or Servlet Cache instance, then it is likely that the Dynamic Cache API calls are being serviced by the baseCache.

To use the WXS dynamic cache provider for JSP, Web services or command caching, then set the baseCache instance to use the WXS dynamic cache provider.

The same configuration properties are used to configure the baseCache instance. Remember that these configuration properties need to be set as JVM custom properties.

This caveat applies to any cache configuration property discussed in this section except for servlet caching.

To use WXS with the dynamic cache provider for servlet caching, be sure to configure enablement in system properties rather than custom properties.


  1. Enable the WXS dynamic cache provider

    • WAS V7.0 and later:

      Use the admin console to configure the dynamic cache service to use the WXS dynamic cache provider

      After installing WXS, the WXS dynamic cache provider is immediately available as a Cache Provider option in the administrative console.

    • WAS Version 6.1:

      Use a custom property to configure the dynamic cache service to use the WXS dynamic cache provider. You can also use these custom properties in WAS v7.0 and later.

      To create a custom property on a cache instance, click...

      Resources | Cache instances | cache_instance_type | cache_instance | Custom properties | New

      If you are using the base cache instance, create the custom properties on the JVM.

      com.ibm.ws.cache.CacheConfig.cacheProviderName

      To use the WXS dynamic cache provider, set the value to...

      com.ibm.ws.objectgrid.dynacache.CacheProviderImpl

      You can create this custom property on a dynamic cache instance, or the base cache instance. If you choose to set the custom property on the base cache instance, then all other cache instances on the server use the WXS provider by default. Any WXS dynamic cache provider configuration properties set for the baseCache are the default configuration properties for all cache instances backed by WXS.

      To override the base cache instance and make a particular dynamic cache instance use the default dynamic cache provider, create the custom property...

      com.ibm.ws.cache.CacheConfig.cacheProviderName

      ...on the dynamic cache instance and set the value to default.

  2. Optional: If you are using replicated cache instances

    3. If you are using replicated cache instances, configure the replication setting for the cache.

    With the WXS dynamic cache provider, you can have local cache instances or replicated cache instances.

    If you are only using local cache instances, you can skip this step.

    Use one of the following methods to configure the replicated cache:

    • Enable cache replication with the administrative console. You can enable cache replication at any time in WAS v7.0. In WAS v6.1, create a DRS replication domain.

    • Enable cache replication with the custom property...

      com.ibm.ws.cache.CacheConfig.enableCacheReplication

      ...to force the cache to report that it is a replicated cache, even though a DRS replication domain has not been assigned to it. Set the value of this custom property to true. Set this custom property on the cache instance if you are using an object cache or servlet cache, or on the JVM if you are using the baseCache instance.


  3. Optional: If you are using WXS as a JSP fragment cache

    4. If you are using WXS as a JSP fragment cache, set the custom property...

    com.ibm.ws.cache.CacheConfig.disableTemplateInvalidation

    ...to true to disable template-based invalidations during JSP reloads.


  4. Configure the topology for the dynamic cache service

    5. The only required configuration parameter for the WXS dynamic cache provider is the cache topology. Set the custom property on the dynamic cache service. Enter the name of the custom property as:

    com.ibm.websphere.xs.dynacache.topology

    The three possible values for this property follow. Use one of the allowed values:

    • embedded
    • embedded_partitioned
    • remote

    If you are using embedded or embedded partitioned topologies, consider setting the custom property...

    com.ibm.ws.cache.CacheConfig.ignoreValueInInvalidationEvent

    ...to true to save some serialization costs. Set this custom property on the cache instance or the JVM if you are using the baseCache instance.


  5. If you are using an embedded partitioned topology

    6. If you are using an embedded partitioned topology, configure the number of initial containers for the dynamic cache service.

    You can maximize the performance of caches that are using the embedded partitioned topology by configuring the number of initial containers. Set the variable as a system property on the WAS JVM.

    Enter the name of the property as: com.ibm.websphere.xs.dynacache.num_initial_containers.

    The recommended value of this configuration property is an integer that is equal to or slightly less than the total number of WAS instances that are accessing this distributed cache instance. For example, if a dynamic cache service is shared between data grid members, then the value should be set to the number of data grid members.

    For embedded or embedded_partitioned topologies, be using Version 7.0 of WAS. Set the following custom property on the JVM process to ensure that the initial containers are available right away.

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


  6. Configure the WXS catalog service grid

    7. When you are using WXS as the dynamic cache provider for a distributed cache instance, configure an WXS catalog service domain.

    A single catalog service domain can service multiple dynamic cache service providers backed by WXS.

    [v7.1 and later] A catalog service can run inside or outside of WAS processes. Starting with WXS V7.1, when you use the administrative console to configure catalog service domains, the dynamic cache uses these settings. It is not necessary to take additional steps to set up a catalog service.

  7. Configure custom key objects.

    8. When you are using custom objects as keys the objects must implement the Serializable or Externalizable interface. When you are using the embedded or embedded partitioned topologies, place objects on the WebSphere shared library path, just like if they were being used with the default dynamic cache provider. See: Use the DistributedMap and DistributedObjectCache interfaces for the dynamic cache.

    If you are using the remote topology, place the custom key objects on the CLASSPATH for the standalone WXS containers. See Start container processes for more information.


  8. Optional: If you are using a remote topology

    9. If you are using a remote topology, configure the WXS container servers...

    • Embedded or embedded partitioned topology:

      The cached data is stored in WXS container servers. Container servers can run inside or outside of WAS processes. The WXS provider automatically creates containers inside the WebSphere process when you are using embedded or embedded partitioned topologies for a cache instance. No further configuration is needed for these topologies.

    • Remote topology:

      When you are using the remote topology, start up stand-alone WXS container servers before the WAS instances that access the cache instance start.

      To start stand-alone container servers, see Start container processes. Verify that all the container servers for a specific dynamic cache service point to the same catalog service endpoints.

      The XML configuration files for the stand-alone WXS dynamic cache provider containers are in either the wxs_install_root/customLibraries/ObjectGrid/dynacache/etc directory for installations on top of WAS, or the wxs_install_root/ObjectGrid/dynacache/etc directory for stand-alone installations. The files are named dynacache-remote-objectgrid.xml and dynacache-remote-definition.xml. Make copies of these files to edit and use when you are starting stand-alone containers for the WXS dynamic cache provider. The numInitialContainers parameter in the dynacache-remote-deployment.xml file must match the number of container processes that are running. Note that the numberOfPartitions attribute in the dynacache-remote-objectgrid.xml file has a default value of 47.

      The set of container server processes must have enough free memory to service all the dynamic cache instances that are configured to use the remote topology. Any WAS process that shares the same or equivalent values for the catalog.services.cluster custom property must use the same set of stand-alone containers. The number of containers and number of servers on which they reside must be sized appropriately. See Dynamic cache capacity planning for additional details.

      A command line entry that starts a stand-alone container for the WXS dynamic cache provider follows:

      [Unix] 

      ./startOgServer.sh container1 
                  -objectGridFile 
                  ../dynacache/etc/dynacache-remote-objectgrid.xml -deploymentPolicyFile 
                  ../dynacache/etc/dynacache-remote-deployment.xml -catalogServiceEndpoints 
                  MyServer1.company.com:2809


  9. Enable the sizing agent to improve memory consumption estimates

    10. For distributed or embedded topologies, enable the sizing agent to improve memory consumption estimates.

    The sizing agent estimates memory consumption (usedBytes statistic). The agent requires a Java 5 or higher JVM.

    Load the agent by adding the following argument to the JVM command line:

    -javaagent:WXS lib directory/wxssizeagent.jar

    For an embedded topology, add the argument to the command line of the WAS process.

    For a distributed topology, add the argument to command line of the WXS processes (containers) and the WAS process.


Parent topic:

Configure cache integration


Related concepts

Dynamic cache provider
Dynamic cache capacity planning


Related tasks

Configure JPA loaders
Configure a JPA time-based data updater
Configure HTTP session managers

Related reference

JPA cache configuration properties


+

Search Tips   |   Advanced Search