Problem:
If you have applied APAR IZ07537 or LI72602, you might notice high CPU
utilization when there are many rows in the CACHEIVL table. There is a
known issue with these APARs where the cache invalidation scheduled job
ignores the last checkpoint. As a result, all invalidation records in the
CACHEIVL table are run every time. Cache entries might get repeatedly
invalidated which degrades overall performance.
Cause:
The following SQL statements are run against the CACHEIVL table in APARs
IZ07537 and LI72602:
select CACHEIVL.TEMPLATE, CACHEIVL.DATAID, CACHEIVL.INSERTTIME from
CACHEIVL where CACHEIVL.INSERTTIME<CURRENT_TIMESTAMP order by
CACHEIVL.INSERTTIME
Instead, the dynacache invalidation job should have used the following SQL
statement if a start time (last checkpoint) is present as part of the job
execution parameter:
select CACHEIVL.TEMPLATE, CACHEIVL.DATAID, CACHEIVL.INSERTTIME from
CACHEIVL where CACHEIVL.INSERTTIME > ? and
CACHEIVL.INSERTTIME<CURRENT_TIMESTAMP order by
CACHEIVL.INSERTTIME
Where the parameter marker is the start time.
You can check that the start time is present with the following query:
select SCCQUERY from SCHCONFIG where SCCPATHINFO =
'DynaCacheInvalidation' and SCCACTIVE = 'A'
If a start time is specified, you will see an output similar to the
following example:
startTime=1207337603000&startTimeNanos=0
Solution:
This problem (APAR LI72725) is resolved in WebSphere Commerce Fix Pack 5
(6.0.0.5) or newer. You can obtain the Fix Pack or newer from the WebSphere Commerce Fixes by version page.
|