Attribute values were updated in the LDAP directly (not via the WebSphere Portal user interface). The updated values are not shown in the Portal. Why is this?
The Portal caches LDAP data. Updates made directly in LDAP are not visible in the Portal because Portal has cached previous values for the attributes.
If you must ensure updates made directly in LDAP are visible in the Portal immediately, both the VMM and PUMA caches should be disabled as described in "Group membership changes made directly in LDAP do not show up immediately."
However, disabling the VMM and PUMA attribute caches can cause performance to degrade. See Note 1 below.
The VMM and PUMA cache lifetime values may be modified to allow the caches to remain enabled while attempting to ensure direct LDAP updates are visible in the Portal after a configurable amount of time has passed. Note that with the caches enabled there is no way to guarantee that LDAP updates are visible immediately.
Consider an update to a user's preferredLanguage attribute. The objective in this scenario is that the update should be visible in the Portal after approximately 2 minutes. The settings described below should only be used as a guide and are not meant to guarantee any particular behavior in your Portal.
Set the cacheTimeOut value to 120 seconds. After 120 seconds the cached result will become invalid. This causes VMM to create a new connection to LDAP to read new results.
<config:attributesCache ... cacheTimeOut="120" enabled="true"/>
<config:searchResultsCache ... />
In the WP_CacheManagerService set the following properties and values:
The value for any cache property does not precisely define when the cached data will become stale. For example, it is possible that the VMM cache timeout is imminent (say, within 1 second) but PUMA requests data from VMM and gets "old" data from the cache. One second later the VMM cache times out but the PUMA cache has just started its lifetime period. The timeout becomes approximately the PUMA lifetime + VMM cache lifetime.
1. Changing cache-related properties may affect performance. Use cases in which case lifetime values are modified are not generally tested by IBM (except where documented elsewhere in performance testing) and IBM Support cannot calculate the potential performance impact that may occur as a result of these changes.
2. Depending on the use case, you may need to modify the lifetime values of PUMA caches that are not listed in this document or you may find you do not need to adjust a Puma cache lifetime at all. A listing of all Puma caches and their contents is outside the scope of this document.
3. Rather than attempt to "tune" the caches to ensure that updates made in the LDAP outside the Portal are visible after some period of time, IBM Support recommends that you consider using facilities provided by APAR PM16430. The code for PM16430 is already integrated in to Portal versions 7 and 8, you need only configure the properties as described in the APAR text.
The APAR enhances the PUMA reload() method so that updates made in the LDAP should be available to Portal immediately after reload() is called. If your code uses PUMA reload() or can be modified to do so, this option is preferable to decreasing cache values, which is imprecise at best.
4. This Technote describes attribute value updates only. The Portal Access Control (PAC) component also maintains cached data. If your use case involves an attribute value update that should then be expected to change a user or group's access to Portal pages or portlets, we cannot expect that modifications to attribute cache timeouts will "refresh" access controls.
Refer to How to programatically refresh data from LDAP for additional details regarding PM16430 and "Addendum to Original Posting" on the same page for a discussion of the access control issue.
5. Be advised that even if the configuration properties provided in PM16430 are enabled, direct LDAP updates will not be visible in the Portal immediately in the Manage Users and Groups portlet, People Finder or other out-of-the-box portlets. This is because the default portlets always use the available caches.
6. The Portal caches attribute data independent of the user repository type, whether this is an LDAP, database or custom repository. For example, if you have a database repository and update attribute values in the database directly, it should be possible to use the technique described in this Technote to make the new value available in the Portal after a period of time.