Configure the WebSphere Commerce application servers

Home | Previous | Next

Configure the WebSphere Commerce application servers

We are now ready to configure the WebSphere Commerce servers to use WXS for storing dynamic cache content by setting properties in the Commerce application servers. We assume there is an existing WebSphere Commerce server or cluster that we are going to configure.

Typically, WebSphere Commerce will already be configured to use the default dynamic cache service, but for completeness we are going to outline the steps to set up the dynamic cache from the beginning to use WXS.
Execute the following steps for each Commerce application server.
Enable servlet caching for the application server to switch on dynamic web caching. This is probably already set by default in Commerce application servers.

In the WebSphere administrative console, click...

Servers | Server Types | WebSphere application servers | Commerce application server | Container Services | Dynamic Cache service | Enable servlet caching

Click OK and save the changes.

Set up the dynamic cache service to use WXS:

On the right of the Commerce application server configuration page, select...

Container Services | Dynamic Cache Service

In the drop down, select WebSphere eXtreme Scale.
This will change the dynamic cache provider for the baseCache (the default cache instance) to use eXtreme Scale.

Leave the cache size as 2000 entries for now.
This is the number of entries that WXS will store per partition configured on the grid.

Verify the Enable cache replication option is enabled.
If not enabled, the WXS configuration we set to dictate the topology will be ignored. Instead, we will actually get a simple local WXS grid in each Commerce server. This is similar to the traditional dynamic cache provider, but a little faster.
When you enable this setting, the rest of the WXS configuration will be applied and, in this scenario, the remote grid will be used.

Click OK and save the changes.
With the WXS dynamic cache provider you can have...

local cache instances
replicated cache instances

If you 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.
To use replicated caches, complete one of the following actions...
Go to...

Administrative console | Java virtual machine | Custom properties | New

...and set...

com.ibm.ws.cache.CacheConfig.enableCacheReplication

...in the Name field, and true in the Value field, and then click OK.

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, you would add the following line to the cacheinstances.properties file:

cache.instance.26.enableCacheReplication = truec
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);
The steps outlined above are specific to WAS and Commerce v7, where we use newer elements of the administrative console to configure the cache. This functionality is available in WAS version 6.1, but is done through the following JVM properties:

com.ibm.ws.cache.CacheConfig.cacheProviderName com.ibm.ws.objectgrid.dynacache.CacheProviderImpl
com.ibm.ws.cache.CacheConfig.enableCacheReplication = true
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

...add the following line to cacheinstances.properties...

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

Set the appropriate dynamic cache properties.
If you already have the dynamic cache service configured for use with Commerce, you probably have many properties already set. It is worth pointing out that any properties that you have set are not used by the WXS provider. They can be safely ignored. This will allow you to revert back to the default dynamic cache provider to test and compare the behavior with WXS.
There is little in the way of additional configuration in WXS because dynamic cache properties are translated to reasonable settings for WXS.

On the right of the Commerce application server configuration page, select...

Java and Process Management | Process definition | Java Virtual Machine | Custom properties

For each of the following properties, click New and enter the name and value for each property.

Custom Property Name

Value

Description

com.ibm.websphere.xs.dynacache.topology

remote

This is the topology we are deploying to. Options include embedded, embedded_partitioned, and remote.

com.ibm.websphere.xs.dynacache.enable_compression

true

This is a performance recommendation to compress the content of the dynamic cache, with the benefits of reduced data to cache and reduced network traffic.

com.ibm.websphere.xs.dynacache.ignore_value_in_change_event

true

This is a performance recommendation where "true" means the cache entry is not de-serialized on the occurrence of a change event.

com.ibm.websphere.xs.dynacache.disable_recursive_invalidate

true

This is a performance recommendation to prevent recursive invalidations of dependency ids. This is a change in behavior, but for a feature rarely used.

com.ibm.ws.cache.CacheConfig.filterLRUInvalidation

true

This property is a dynamic cache recommendation and not specific to WXS. It prevents the creation of invalidation events in the case of least recently used (LRU) eviction, which can cause large object allocations. More information about this setting can be found at:
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg1PK24146

com.ibm.ws.cache.CacheConfig.filterTimeOutInvalidation

true

This property is a dynamic cache recommendation and not specific to WXS. It prevents the creation of invalidation events in the case of time out eviction, which can cause large object allocations. More information about this setting can be found at:
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg1PK24146

com.ibm.ws.cache.CacheConfig.disableTemplateInvalidation

true

This is a performance setting recommended to prevent invalidation based on cache templates, which is more expensive in WXS.

com.ibm.ws.cache.CacheConfig.useServerClassLoader

true

This is a performance recommendation to specify which class loader to use to (de)serialize event information instead of dynamically having to determine the class loader. Commerce provides classes for this and therefore uses the server class loader. More information about this setting can be found at:
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg1PK15310

Performance properties for the dynamic cache service
The results are shown in Figure 6-16.

Repeat steps a to c for the other Commerce application servers.
Configure the WebSphere eXtreme Scale replication topology
Go to...

administrative console | Java virtual machine | Custom properties page | New

...and enter...

com.ibm.websphere.xs.dynacache.topology

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

embedded
embedded_partitioned
remote

If you specify embedded_partitioned, add the property...

com.ibm.websphere.xs.dynacache.num_initial_containers

...to your 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.

Add the com.ibm.websphere.xs.dynacache.topology 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, you would add the following line to the cacheinstances.properties file: cache.instance.26.enableCacheReplication = embedded Avoid trouble: If you specify embedded_partitioned, also add the 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.gotcha For example, if a dynamic cache service is shared between grid members, then the variable should be set to the number of grid members.
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);
Configure the eXtreme Scale catalog service grid.
When you run a catalog service grid, set the catalog.services.cluster custom property for the catalog service endpoints.

In the administrative console, click System administration > Cell > Custom properties > New.

Enter catalog.services.cluster in the Name field, and the appropriate...

server_name:host_name:client_port:peer_port:listener_port

...in the Value field.

server_name 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 that is used for peer catalog grid communication.
peer_port is the port that is used for peer catalog grid communication.
listener_port is the listener port. This port must match the BOOTSTRAP_ADDRESS value that is 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:2809c

Click OK.

Click Save to save all of the configuration changes.

Restart all the application servers that you configured to use WebSphere eXtreme Scale.

Configure custom key objects.
When you are using custom objects as keys, the objects must implement the Serializable or Externalizable interface. If you are using custom objects with the embedded or embedded partitioned topologies, place the objects on the shared library path, in the same way that you do if you are using the default dynamic cache provider. For more information, see the topic Using 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 stand-alone WXS containers.
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 WXS provider automatically creates containers inside a WAS process when you are using embedded or embedded partitioned topologies for a cache instance. No further configuration is needed for these topologies.
When you use the remote topology, start up stand-alone WXS containers before you start the WAS instances that access the cache instance.
Avoid trouble: Make sure that all the containers for a specific dynamic cache point to the same catalog service endpoints. gotcha
The dynacache-remoteobjectgrid. xml and dynacache-remote-definition.xml configuration files for the standalone WXS Dynamic Cache provider containers are located in...

install_root/customLibraries/ObjectGrid/dynacache/etc

...if WXS is installed on top of WAS, or in...

install_root/ObjectGrid/dynacache/etc

...if you are using a stand-alone version of WXS. Make copies of these files to edit and use when launching standalone containers for the WXS 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 standalone 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 
Avoid trouble: 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 standalone containers. The number of containers and number of machines they reside on needs to be sized appropriately.
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 WebSphere eXtreme Scale fails the dynamic cache runtime reverts to the default dynamic cache cache provider, and you 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.
You can save yourself having to type in lots of properties many times by fully configuring the first application server and then using the WebSphere template functionality to save it. In the administrative console,

Select...

Servers | Server Types | WebSphere application servers

From that page, select the configured application server and click Templates....

Select the Commerce application server configured and provide a template name.
This template can be used to create new servers or clusters with the properties and dynamic cache provider already configured.

Save the changes.

At this point, the Commerce application servers have the WXS dynamic cache provider fully configured for the baseCache cache instance. You might want to test that this is properly configured.
There are a few WebSphere Commerce-specific optimizations that we will make in the next section before the environment is completely ready.

+
Search Tips | Advanced Search

Custom Property Name	Value	Description
com.ibm.websphere.xs.dynacache.topology	remote	This is the topology we are deploying to. Options include embedded, embedded_partitioned, and remote.
com.ibm.websphere.xs.dynacache.enable_compression	true	This is a performance recommendation to compress the content of the dynamic cache, with the benefits of reduced data to cache and reduced network traffic.
com.ibm.websphere.xs.dynacache.ignore_value_in_change_event	true	This is a performance recommendation where "true" means the cache entry is not de-serialized on the occurrence of a change event.
com.ibm.websphere.xs.dynacache.disable_recursive_invalidate	true	This is a performance recommendation to prevent recursive invalidations of dependency ids. This is a change in behavior, but for a feature rarely used.
com.ibm.ws.cache.CacheConfig.filterLRUInvalidation	true	This property is a dynamic cache recommendation and not specific to WXS. It prevents the creation of invalidation events in the case of least recently used (LRU) eviction, which can cause large object allocations. More information about this setting can be found at: http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg1PK24146
com.ibm.ws.cache.CacheConfig.filterTimeOutInvalidation	true	This property is a dynamic cache recommendation and not specific to WXS. It prevents the creation of invalidation events in the case of time out eviction, which can cause large object allocations. More information about this setting can be found at: http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg1PK24146
com.ibm.ws.cache.CacheConfig.disableTemplateInvalidation	true	This is a performance setting recommended to prevent invalidation based on cache templates, which is more expensive in WXS.
com.ibm.ws.cache.CacheConfig.useServerClassLoader	true	This is a performance recommendation to specify which class loader to use to (de)serialize event information instead of dynamically having to determine the class loader. Commerce provides classes for this and therefore uses the server class loader. More information about this setting can be found at: http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg1PK15310