Direct links to fixes
APAR status
Closed as program error.
Error description
The refresh of the promotion and marketing registries needs to be done manually using the IBM WebSphere Commerce Administration console when promotion and marketing data in the database tables is changed. Furthermore, even with APAR JR38740 or LI75521 installed, the default values for the maxSeconds and waitSecondsAfterRefreshRegistry parameters may prevent the DynacacheInvalidation scheduler job from completing in a timely manner.
Local fix
Refresh registries manually using WebSphere Commerce Administration consol
Problem summary
USERS AFFECTED: Customers that frequently make changes to the promotion and marketing data in the database PROBLEM ABSTRACT: Automate refresh of PromotionRegistry, PromotionPolicyRegistry, PromotionGroupRegistry and CampaignInitiativeCache registries after underlying Promotion and Marketing database tables are updated BUSINESS IMPACT: Lost productivity due to having to manually refreshing the registries. If the manual refresh is not done at the right time, obsolete marketing and promotion data can be displayed to shoppers. RECOMMENDATION: Install this IFix 1689
Problem conclusion
This fix can be used to cause the promotion registries to be refreshed within a specified amount of time after the promotion tables are updated. It also can be used to cause the CampaignInitiativeCache registry to be refreshed within a specified amount of time after the EMSPOT or DMACTIVITY tables are updated. The DynaCacheInvalidation scheduler job has the following new properties, which can be specified in the SCHCONFIG.SCCQUERY database column: 1. enableRefreshRegistry (defaults to "true"). When the enableRefreshRegistry property does not specify "false", the DynaCacheInvalidation scheduler job inspects each value found in the CACHEIVL.DATAID column and if it is of the form "WCR+<registryName>", it will add a broadcast scheduler job that will cause the specified registry to be refreshed on every currently running Commerce server. 2. waitSecondsAfterRefreshRegistry (defaults to the minimum of the "cycleTime" property of the "com.ibm.commerce.scheduler.SchedulerComm" component defined in the wc-server.xml WebSphere Commerce instance configuration file, and the value of the SCHCONFIG.SCCINTERVAL column for the DynaCacheInvalidation scheduler job, or 600 if that column is null or less than or equal to zero). When the waitSecondsAfterRefreshRegistry property specifies a value greater than or equal to zero, the DynaCacheInvalidation scheduler job will pause for the specified number of seconds before issuing DynaCache invalidations. Specify a number that allows enough time for the broadcast job to complete on all servers. 3. maxSecondsPerTransaction (defaults to 60) specifies the number of seconds since the beginning of the database transaction after which the job will try to pause processing, commit, and begin a new transaction to continue the work. The actual time used by the transaction may exceed that number. In the case where isDistinct=true, the time may far exceed that number, since all found distinct rows must be processed in the same transaction. 4. maxSeconds specifies an overall duration for the potentially multiple transactions executed by a single job instance. The actual duration may exceed that number. When that duration is reached, the job tries to end as soon as it can, and may leave unfinished work to be done by the next execution of the same job. The duration does not include time spent waiting as specified by the waitSecondsAfterRefreshRegistry parameter, and does not include time spent waiting for an update lock on the SCHCONFIG row for this job execution. The default value is 90% of the value in the SCCINTERVAL column (if the value in the column is zero, then maxSeconds=0 is used, indicating there is no limit). 5. isDistinct (defaults to "false"). When the isDistinct=true property is specified, only one row is returned for each unique pair of values found in the CACHEIVL.TEMPLATE and CACHEIVL.DATAID columns. This generally has the effect of speeding up the processing, but there are two possible side effects. The first side effect is that the sequence of the invalidations issued may be affected, which can cause different caching behaviour on a busy system when the cache entries are built from other cached data at the same time the invalidations are being issued. The second side effect is that all invalidations must be issued within a single transaction, so if there are too many a transaction timeout may occur. To ensure that all required invalidations are issued, when isDistinct=true and a transaction timeout occurs, the transaction is re-tried specifying isDistinct=false. The maxSecondsPerTransaction and maxSeconds parameters help avoid a transaction timeout, by allowing the work to be done in multiple transactions. To avoid unnecessary duplication of work, each transaction will first obtain an Update database lock on the row of the SCHCONFIG table for the currently running scheduler job. When the transaction commits, the SCCQUERY value is updated with the timestamp information that should be used by the next job execution. To avoid unnecessarily holding multiple threads waiting on the same Update lock in the same JVM, jobs that are started before a job currently executing in the same JVM has completed return immediately, indicating successful completion. Previously, with APARs JR38740 and LI75521, the maxSeconds parameter specified the maximum duration of the DynacacheInvalidation scheduler job, including time spent waiting. This caused very slow processing when the default parameter values were used, since the default value for maxSeconds was less than the default value for waitSecondsAfterRefreshRegistry. In this fix, the duration of the job is redefined to not include time spent waiting as specified by the waitSecondsAfterRefreshRegistry parameter, and to not include time spent waiting for an Update lock on the SCHCONFIG row for this job execution. This fix also provides additional database triggers on the PX_PROMOTION, PX_GROUP, PX_POLICY, and PX_GRPPOLICY tables. The triggers cause a row to be written to the CACHEIVL table each time one of the tables is updated. The CACHEIVL rows that are added place the following values in the DATAID column: WCR+PromotionRegistry WCR+PromotionGroupRegistry WCR+PromotionPolicyRegistry This fix also provides additional database triggers on the EMSPOT and DMACTIVITY tables. The triggers cause a row to be written to the CACHEIVL table each time the EMSPOT or DMACTIVITY tables are updated. The CACHEIVL rows that are added place the following value in the DATAID column: WCR+CampaignInitiativeCache The new triggers are defined in the schema/<database>/wcs.cacheivl.trigger.sql database script file, and are not enabled by default. ------------------------------------------------------------- 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 number
LI76485
Reported component name
WC BUS ED ILINU
Reported component ID
5724I3804
Reported release
600
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2011-11-01
Closed date
2012-01-12
Last modified date
2012-01-12
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 ED ILINU
Fixed component ID
5724I3804
Applicable component levels
R600 PSY
UP
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSYSYL","label":"WebSphere Commerce Enterprise"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"6.0","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
12 January 2012