Enabling WCS Data Cache

Caching data in WCS can be done in 2 ways using:

1. Command Caching: The data that can be cached can be chosen and then the configuration can be fine tuned by modifying the cache configurations in cachespec.xml
2. DistributedMap objects configuration methods: This can be done by defining specially named object caches in the cacheinstances.properties file. Some DistributedMap object caches are defined automatically during feature pack installation. To view these object caches, open the WebSphere Application Server Integrated Solutions Console, and on the left menu, click Resources > Cache instances > Object cache instances.

In this topic we are specifically going to focus on the Distributedmap caching.

Object caching in specified DistributedMap instances causes each type of data to be cached in its corresponding DistributedMap object. When this method is used, the cachespec.xml configurations are not used for the kinds of data that has a corresponding DistributedMap defined. We cannot fine-tune the priority, timeout, or inactivity settings by using the cachespec.xml configuration file. However, we can specify other DistributedMap attributes, such as the maximum number of cache entries to be used by each DistributedMap.

There are two ways we can define DistributedMap objects:

1. Define DistributedMap objects with the default JNDI names in the cacheinstances.properties file in the following directory:    WCDE_installdir\samples\dynacache\

We can copy and paste selected contents of the samples\dynacache\cacheinstances.properties file into the custom cacheinstances.properties file in the Stores.war\WEB-INF\classes directory.

      2.Use the WebSphere Application Server Integrated Solutions Console. From the left menu, click Resources > Cache instances > Object cache instances.

In a clustered environment, make sure that a replication domain is defined, and at least the services/cache/WCSessionDistributedMapCache object cache is defined. All object caches must enable cache replication (notShared replicationType 1) to allow invalidation IDs to be sent to all nodes in the replication domain. Otherwise, invalidation IDs are not sent to all nodes in the replication domain, resulting in incorrect results due to stale data in some cache instances. Make sure to specify the replication domain and a valid replication type. The "not shared" replication type is recommended.

Summarizing the steps to using DistributedMap Cache:

1. Configure the cacheinstances.properties file in the Stores.war\WEB-INF\classes directory. The same file can e used as such unless any specific changes are required.
2. The list of objects cached under each cache name will be listed in the below page. Please check the same for any issues/to clear any specific cache.
   https://www.ibm.com/support/knowledgecenter/SSZLC2_7.0.0/com.ibm.commerce.admin.doc/refs/rdclogcachnameDM.htm
3. Enable CrossTransactionCache in wc-server.xml
4. Load Cache Monitor to view the below caches enabled
   
   
       http://localhost/cachemonitor
5. By the below methods data cache can be used efficiently
   

   Using cache enabled access beans 

          This maximize the performance of the customization since it contain methods which leverage Commerce data cache and are faster for subsequent executions. They have the methods with the same input parameters as that of standard version and there is no reason not to use them as they are functionally equivalent to the latter.

        Standard Version:
       
        CatalogEntryAccessBean catentryAccessBean = WCDataCache.newCatalogEntryAccessBean();
        catentryAccessBean.setInitKey_catalogEntryReferenceNumber("10001");
       
        Cache Enabled Version:
       
        CatalogEntryAccessBean catentryAccessBean = new CatalogEntryAccessBean();
        catentryAccessBean.setInitKey_catalogEntryReferenceNumber("10001");
        catentryAccessBean.refreshCopyHelper();
       
        Cache invalidation: Invalidation of cache entries generated by the cache enabled access beans is taken care of by the data cache framework.
   

    Enabling custom query caching

    We can execute and cache custom SQL statements using features of the WCDataCache class. SQL statement caching should be considered based on the data access frequency, result set size and data
   
        Standard Version:
       
        String query = "select value from catentry where catentry_id = ?";
        ServerJDBCHelperAccessBean jdbcAccessBean = new ServerJDBCHelperAccessBean();
        Serializable[] parameters = new Serializable[1];
        parameters[0] = this._catentryId;

        Vector results = jdbcAccessBean.executeParameterizedQuery(query, parameters);
        for (int i = 0; i < results.size(); i++) {
            Vector resultVector = (Vector) results.get(i);
        }
              
        Cache Enabled Version:
       
        //Provide the information needed to generate dependency ids.
        TreeMap columnMap = new TreeMap();
        columnMap.put("CATENTRY_ID", this._catentryId);

        ArrayList listMaps = new ArrayList();
        listMaps.add(columnMap);

        TreeMap tableMap = new TreeMap();
        tableMap.put("CATENTRY", listMaps);

        //Execute the query. Passing null as logical cache name will select WCMiscDistributedMapCache.
        Enumeration r = WCDataCache.executeParameterizedQuery("SELECT PARTNUMBER FROM CATENTRY WHERE CATENTRY_ID = ?",
                new Serializable[] {this._catentryId}, 0, tableMap, null, null);
           
        //And retrieve results.
        while(r.hasMoreElements()) {
            List row = (List)r.nextElement();
            if(this._partNumber.equals(row.get(0))) {
                catentryFound = true;
            }
        }

        Cache Invalidation: Invalidation of cache entries generated by the WCDataCache.executeParameterizedQuery method is automatic for out of the box database tables, we only need to make sure that the DynaCacheInvalidation job is scheduled and that generated dependency ids match cache invalidation trigger patterns for a database table.
       
        Invalidation triggers of cached query results for out of the box database tables: C:\IBM\WCDE80\schema\<DB>\wcs.cacheivl.trigger.sql
        Invalidation of cached query results for custom database tables can be performed by the following ways:

•  adopting cache invalidation triggers

•  using the clearCache

•  issueInvalidations method defined in the WCDataCache class

•  generateAndIssueInvalidationsForTable method defined in the WCDataCache class

    PFB an example of how an invalidation can be performed using the WCDataCache class:
           
            TreeMap columnMap = new TreeMap();
            columnMap.put("CATENTRY_ID", this._catentryId);
            WCDataCache.generateAndIssueInvalidationsForTable("CATENTRY", columnMap, WCDataCache.getDeleteOperationMask());
   
    Reference:
    https://www.ibm.com/developerworks/community/blogs/wcs/entry/Supercharge_Custom_Code_Using_Data_Cache?lang=en
    https://www.ibm.com/support/knowledgecenter/en/SSZLC2_7.0.0/com.ibm.commerce.admin.doc/refs/rdcdatbeanclassextadv.htm
    https://www.ibm.com/support/knowledgecenter/en/SSZLC2_7.0.0/com.ibm.commerce.admin.doc/tasks/tdcenabcommdatacache.htm