IBM Support

LI76485: CMVC 214935 - CORRECT DYNACACHEINVALIDATION JOB'S WAIT TIME AFTER REFRESHING THE REGISTRIES.

Subscribe

You can track all active APARs for this component.

 

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