Caching Issue in WebSphere Portal version 6.1, 7.0 and 8.0

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
   where 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
   where 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.

Full technote and source : http://www-01.ibm.com/support/docview.wss?uid=swg27037929&myns=swgws&mynp=OCSSHRKX&mync=E#!