JR45569: CMVC 226843 - ADD ATTRIBUTE CACHING FOR GETCATALOGNAVIGATIONVIEW BOD RESPONSE

7.0.0-WS-WCServer-FP009
WebSphere Commerce Version 7.0.0.8 Fix Pack
WebSphere Commerce Version 7.0.0.9 Fix Pack

APAR status

• Closed as program error.

Error description

• Caching was added in FEP5 to correct this; this is a backport
  APAR to add in this caching to SolrSearchConfigurationRegistry
  

Local fix

Problem summary

• USERS AFFECTED:
  V7 users using Solr search with a large number of attributes in
  their catalog
  
  PROBLEM ABSTRACT:
  On search display pages, for displaying facets, repeated
  attribute dictionary service calls is causing a performance
  impact.
  
  BUSINESS IMPACT:
  Performance impact; search results take longer, scaling upwards
  with the number of attributes
  
  RECOMMENDATION:
  

Problem conclusion

• This iFix implements caching of some frequently executed SQL
  queries to the ATTRDESC table.
  
  The cache entries are cached using the
  com.ibm.commerce.foundation.internal.server.services.search.conf
  ig.solr.SolrSearchConfigurationRegistry.NAME logical data cache
  in the WCSearchAttributeDistributedMapCache object cache.  In
  Feature Pack 4, the default size of this object cache was 10.
  To take advantage of the additional caching in this iFix, that
  cache size should be increased, for example, to 5000.  Use the
  WebSphere Application Server administration console to increase
  the cache size.  Select from the left:  Resources, Cache
  instances, Object cache instances, and click on
  WCSearchAttributeDistributedMapCache.
  
  Note:  increasing the cache size will increase the memory
  footprint of the application server JVM.  It is recommended to
  do performance testing with verbose GC tracing enabled to make
  sure that the JVM heap allocated does not exceed 55% even when
  all caches are full.  The IBM Extended Cachemonitor application
  can be used to monitor object cache sizes.
  
  For more information about configuring logical data caches,
  refer to:
  
  http://pic.dhe.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.co
  mmerce.admin.doc/tasks/tdccdccont.htm
  
  When changes are made to the information in the ATTR and
  ATTRDESC database tables, these new cache entries become stale
  and need to be invalidated (removed from the cache).  To make
  sure entries are properly invalidated when, or soon after, they
  become stale, you should define the database triggers provided
  in the following file:
  
  components\foundation\schema\fep4\<database-type>\wcs.cacheivl.t
  rigger.sql
  
  The triggers insert a row into the CACHEIVL database table each
  time a row of the ATTR or ATTRDESC tables is changed.  The
  DynacacheInvalidation scheduler job should be configured to run
  periodically.  Each time it runs it reads recently added rows in
  the CACHEIVL table, and issues the appropriate cache entry
  invalidation messages to DynaCache.  For more information about
  the DynaCacheInvalidation scheduler job, refer to:
  
  http://pic.dhe.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.co
  mmerce.developer.doc/refs/rdcinvalid.htm
  
  The triggers can be removed by the commands provided in the the
  following file:
  
  components\foundation\schema\fep4\<database-type>\wcs.cacheivl.d
  rop.trigger.sql
  
  -------------------------------------------------------------
  The latest available maintenance information can be obtained
  from the Recommended Fixes for WebSphere Commerce technote:
  http://www.ibm.com/support/docview.wss?rs=3046&uid=swg21261296
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  WC BUS EDITION

• Fixed component ID

  5724I3800

Applicable component levels

• R700 PSY

     UP