Cache invalidation can quickly become one of the major bottlenecks of any ecommerce site, and given we end up with multiple cached layers, in a complex architecture it is important to tailor together the sequence in which cache should be evicted without impacting site stability.
In this section we will explore server side cache management in WCS and some of the common pitfalls and design considerations.
WCS in general has pretty good architecture for server side cache it inherits from WAS dynacache infrastructure which is pretty matured and adds on top of it WCS components for cache management.
Local Cache Topology
Cached components are stored locally in JVM, dynacache takes a slice of JVM heap space to store cached data, hence in a 32 bit architecture you will very quickly be out of room if you need to store more than 2 GB of data. At this point you should explore the option of a 64 bit JVM so a local cache can store more data.
Local cache is a good candidate for smaller cluster, for larger implementations maintenance of cached copy of data per JVM and data invalidation traffic can become overwhelming at times and hence a remote cache option should be explored.Remote Cache Topology
WCS currently only supports WXS as remote cache sever, the plugin is available OOB and works seamlessly without any need to modify the code, In remote topology dynacache cache content is stored remotely in WXS server and hence invalidation of data happens across multiple WXS dynacache container. this configuration is preferred for sites that store large amount of data in dynacache and need to refresh and invalidate cache often.
Cache Invalidation Steps
For both local and remote topology WCS makes use of Dynacache invalidation job for cache eviction, Dynacache invalidation job depends on dynamic cache services to replicate the invalidation of local cache In a topology where in dynacahe is local to JVM and is a clustered environment.WAS DRS (Dynamic replication service) internally depends on WAS HAManager service for replication,
hence it is important that you configure and turn on both DRS and WAS HAManager failing which may result in inconsistent cache conten and data generation across the cluster.
Step 2: Data from stage prop is populated in corresponding tables in production database and an entry is created in cacheivl for every create, update, delete operation performed on the table, the entries in the table represent the cache dependency id that should be invalidated so a new cache is built by reading the respective datastore.
WCS cachespec.xml defined a cache dependency id
Step 3:
WCS Dynacache Invalidation Job processes cacheivl records, the records are not deleted or marked as processed, or in other words there is no way you can ever query all processed records from WCS cacheivl table.
Instead, WCS Dynacacheinvalidation job uses a special field startTime and startTimeNanos to identify the records timestamp that needs to be processed from cacheivl table for next run of the job, When the Job is run the state is changed to 'R', which means it is in running state currently.
UPDATE SCHACTIVE SET SCSSTATE='R', SCSQUEUE=?('localhost:-2cced56d:13a3876cf3e:-8000:'), OPTCOUNTER=16652 WHERE SCSINSTREFNUM=52502 AND OPTCOUNTER = 16,651 OR OPTCOUNTER IS NULL
SCHCONFIG.SCCQUERY by default has value of 'startTime=0&startTimeNanos=0' for the very first execution of this JOB, startTime and startTimeNanons refer to timestamp is long format, they are updated to the timestamp of last record that was processed from CACHEIVL table towards the end of the job execution.
UPDATE SCHCONFIG SET SCCHOST = ?(null), SCCSTART = ?(9/30/12 9:20 PM), STOREENT_ID = ?(0), SCCPRIORITY = ?(1), SCCSEQUENCE = ?(0), SCCRECDELAY = ?(0), SCCACTIVE = ?('A'), SCCRECATT = ?(0), SCCAPPTYPE = ?(null), SCCPATHINFO = ?('DynaCacheInvalidation'), MEMBER_ID = ?(-1,000), SCCQUERY = ?('startTime=1348772158228&startTimeNanos=228000000'), INTERFACENAME = ?(null), SCCINTERVAL = ?(100), OPTCOUNTER = ?(29,941) WHERE SCCJOBREFNUM = ?(52,002) AND OPTCOUNTER = ?(29,940)
The next run of the job then would process the records from where it left last time around and based on the updated values of startTime and startTimeNanos.
select CACHEIVL.TEMPLATE, CACHEIVL.DATAID, CACHEIVL.INSERTTIME from CACHEIVL where CACHEIVL.INSERTTIME<CURRENT_TIMESTAMP and CACHEIVL.INSERTTIME>12/31/69 6:00 PM order by CACHEIVL.INSERTTIME
Hint: To reprocess all the records from CACHEIVL we can run following update Query
update schconfig set SCCQUERY='startTime=0&startTimeNanos=0' where
sccpathinfo='DynaCacheInvalidation' and SCCACTIVE='A';
Once the Job completes a record is inserted in SCHSTATUS table
INSERT INTO SCHSTATUS (SCSINSTREFNUM, SCSEND, SCSRESULT, SCSQUEUE, SCSSTATE, SCSSEQUENCE, SCSACTLSTART, SCSATTLEFT, SCSPREFSTART, SCSJOBNBR, SCSINSTRECOV, OPTCOUNTER) VALUES (?(67,078), ?(null), ?(null), ?('localhost:-2cced56d:13a3876cf3e:-8000:default'), ?('R'), ?(0), ?(10/6/12 7:26 PM), ?(0), ?(10/6/12 7:26 PM), ?(52,002), ?(0), ?(22,283))
Job state in SCHACTIVE table is changed to 'I', which indicates it is scheduled to run again at
SCHACTIVE.SCSPREFSTART
UPDATE SCHACTIVE SET SCSSTATE=?('I'), SCSPREFSTART=?(10/6/12 7:28 PM), SCSQUEUE = NULL, OPTCOUNTER=?(16,653) WHERE SCSINSTREFNUM=?(52,502) AND (OPTCOUNTER = ?(16,652) OR OPTCOUNTER IS NULL)
To clear all cache entries we can create following entry in cacheivl with "clearall" string
insert into cacheivl
(template, dataid, inserttime)
values(null,'clearall',sysdate)
Use the following log trace components to debug issues with Dynacache
Client side logging
*=info:com.ibm.websphere.commerce.WC_SERVER=all:com.ibm.websphere.commerce.WC_CACHE=all: com.ibm.ws.cache.*=all
Logging on WXS server
com.ibm.ws.objectgrid.dynacache*=all=enabled
Further Reading
