Portal v7002 fixpack installation fails with "Target `check-portal-level-CF' does not exist in this project

When installing the Portal v7002 fixpack on a binary Portal installation after installing any cumulative fix, the 7002 fixpack installation may fail with "Target `check-portal-level-CF' does not exist in this
project"

Symptom

In the console output at the time of the failure, you see the following exception:
=============================
Result: StdErr: BUILD FAILED
Result: StdErr: Target `check-portal-level-CF' does not exist in this project. It is used from target `action-validate-portal-version-for-multProfile-CF'.
Result: StdErr:
Result: StdErr: Total time: 4 seconds
Log: ExecCmd::launch returns 1
Task 2 out of 630; End Uninstalling fix ' PM49013', component 'wp.ptf.config'.
Task 3 out of 630; Begin Completing fix ' PM49013' subTmpDir to be cleaned up: /tmp/ptfs
The directory does not exist, or is not a directory, continue to run: /tmp/ptfs
Fix pack installation has failed. Consult
/usr/WebSphere7/PortalServer/version/log/20120217_085936_PM49013_uninsta
ll.log for error details.
chmod -R 550 /usr/WebSphere7/PortalServer done!
UpdateInstaller.puiReturnCode is 9
End of [ ./updatePortal.sh ]
=============================

A similar error can be seen in the ConfigTrace.log as well.

Cause

This issue occurs when the user has done the following:

- Installed Portal as a binary installation

- Upgraded Portal to v7001 + any CF

- Created a profile (or migrated)

- Updated the wps.properties with the new profile information

- Attempted to upgrade to v7002

The first step for any fixpack installation is to remove all fixes and cumulative fixes. The CF uninstall fails in this case and that is why the fixpack fails.

The CF uninstall fails because of a defect in the Portal Update Installer that prevents any fix or CF from uninstalling cleanly when it was originally installed on a binary install. This will be fixed in a later version of the Portal Update Installer.

Resolving the problem

If you encounter this exception, you must take the following steps to resolve it:

1. Edit the PortalServer/wps.properties file
2. Remove the ProfileName and ProfilePath parameters from it.
3. Manually uninstall the cumulative fix(es) you have applied
4. If the following file still exists after the CF uninstall, manually remove it:

PortalServer/installer/wp.config/config/includes/preconfig_cumulative_fix.xml

5. Edit the PortalServer/wps.properties file again and add ProfileName and ProfilePath back to the file.
6. Reattempt the 7002 fixpack installation.

Source :  http://www-01.ibm.com/support/docview.wss?uid=swg21585265

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#!