Caching in WebSphere Portal version 6.1, 7.0 and 8.0

Product documentation


Abstract

In the area of caching in WebSphere Portal, some issues occurred. This technote informs you how they had been solved. As the code base has changed over the years, fixes apply only to specific releases

Content

Currently Committed database setting - Applies to DB2 v9.7 or higher and WebSphere Portal version 6.1 and 7.0

DB2 V9.7 introduced a new default behaviour for isolation level cursor stability (CS) (see http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.config.doc/doc/r0053556.html).
In WebSphere Portal this has implications for the cache invalidation strategy related to transactions. The new DB2 default behaviour for isolation level cursor stability (CS) is to NOT block code that wants to read data which is still being worked on in an uncommitted transaction in another thread (DB2 returns the result, as if the other transaction would not exist). But WebSphere Portal version 6.1 and 7.0 cache invalidation and refill strategies rely on the blocking at database level. With the new 'currently committed' default setting, stale data in Portal caches can occur.

Starting with Portal version 8.0 the setting of CUR_COMMIT to ENABLED is supported.

Besides the fact that CUR_COMMIT must be set to DISABLED for WebSphere Portal version 6.1 and 7.0, WebSphere Portal development does not expect a performance degradation when changing the value of CUR_COMMIT from ENABLED to DISABLED. For some scenarios with long database transactions, it could be that response times increase due to additional waits for updated data.

The setting of CUR_COMMIT is applied at database level. Therefore it is required to set CUR_COMMIT to DISABLED for the Portal database(s), containing the Portal database domains release, community, customization, jcr, feedback, and likeminds.

Disabling CUR_COMMIT in DB2 Version 9.7:

Ask your DB2 administrator to ensure that CUR_COMMIT is disabled by carrying out the following steps (for each of the Portal databases):

    1. Connect to the runtime database:
      $ db2 connect to <DB_NAME>
      where <DB_NAME> represents the name of the database.
    2. List the CUR_COMMIT parameter:
      $ db2 get db cfg show detail | grep CUR_COMMIT
      The output should look like this:
      Currently Committed (CUR_COMMIT) = DISABLED DISABLED
    3. If the values are anything other than two times DISABLED (one for the current setting used, the other for the delayed setting specified in the configuration), change the value to DISABLED:
      $ db2 update db cfg using CUR_COMMIT DISABLED
    4. Close the database connection:
      $ db2 connect reset
    5. Check that no other application is connected to the database,to make the change effective (This e.g. requires to stop the Websphere Portal Server that uses the database). List the connected applications like this:
      $ db2 list applications for db <DB_NAME>
      where <DB_NAME> represents the name of the database.
      The output should look like this:
      SQL1611W No data was returned by Database System Monitor.
    6. Ensure that the settings are correct by repeating the steps 1. and 2.


For WebSphere Portal version 6.1 the following caching APAR is recommended
For WebSphere Portal version 7.0.0.2 and 8.0 the following caching APARs are recommended
  1. Included in version 7.0.0.2 CF022, version 8.0.0.0 CF05, and version 8.0.0.1 CF05 or higher:

Rate this page:

(0 users)Average rating

Document information


More support for:

WebSphere Portal
Problem Determination

Software version:

6.1, 7.0, 8.0

Operating system(s):

AIX, HP-UX, IBM i, Linux, Solaris, Windows, i5/OS, z/OS

Reference #:

7037929

Modified date:

2014-04-16

Translate my page

Machine Translation

Content navigation