ShowTable of Contents
WebSphere Personalization (PZN) uses many different types of caching. There are three main different types of caching, Internal Cache, Resource Domain, Visibility Rule Caching. Internal cache, resource domain are covered in the Best Practices for using Personalization (
http://www-10.lotus.com/ldd/portalwiki.nsf/dx/personalization-best-practices) and won't be covered in depth in this document. This document will cover visibility rule caching, possible problems with visibility rule caching, the differences between visibility rule caching and regular cache, how to manage the cache and a look into the caching API.
Visibility rule caching is only used for visibility rules, and is not used for anything else. This cache takes the results of a visibility rule, show or hide and stores the results in a cache. This will happen for all visibility rules, so if the visibility rule is meant to use dynamic data, the results will not change based on the dynamic data.
This is what happens if a rule runs with dynamic data. The rule will run once based on a the original data, then the results will be cached. When the rule is called again it will not execute again, the results will be taken from the cache. This is not affected by any data changing.
Visibility rules are cached on a per rule. This can be overcome by disabling the cache globally or invalidated via some code which is running. The visibility rule caches lasts per session ( from user login to user log out ).
This is different then the other caches because this cache just stores the results, it does not look at the data to see if it might have changed. Visibility rules also uses the other caches in PZN, as well when the rule executes. The visibility rule cache is on top of the other caches with in pzn, the last item to be cached and the first item to be looked at. This may cause the visibility to react to data which is not expected, because the personalization cache may be stale.
If you are having trouble with a visibility rule try disabling the cache, and sees if that fixes the issue. The rule may have been run before the data is cached. This cause all other time the visibility rule to show the bad results.
The behavior of visibility rule cache changed with PK61143 and PK62311 in 6.0.1.3. Anything after 6.0.1.3 the cache is used more heavily and is more noticeable. If upgrading portal to a version after 6.0.1.3, visibility rule caching should be investigated to see if it will affect the portal instance.
Performance impact of disable visibility rule cache
When any type of cache is disabled there may be a performance impact. This depends on a lot of factors, how many visibility rules are running, how many users and how complex the visibility rule is. These are some of the main factors in determining the performance impact, but there may be others depending on the setup. If the visibility rules are not complex and do not take a long time to run, most likely the impact will not be noticeable, if the cache is disabled. If there are a lot of complicated rules, which takes a long time to run then there will be a performance impact. This all depends how the system is designed. It is all a balance. The rules can also be redesigned to take use of other caching with in personalization.
Disabling the Caches
Disabling the general cache for personalization will NOT disable the visibility rule caching. It is a different settings.
The first step is to locate the right configuration file, all caches uses the same files. The configuration file is located in different place depending on the version of portal.
6.0: <portal_root>/shared/app/config/services/PersonalizationService.properties
6.1: <wp_profile>/PortalServer/config/config/services/PersonalizationService.properties
*** NOTE There are other files called PersonalizationService.properties which should NOT be used ***
*** DO NOT USE ***
<wp_profile>/PortalServer/wcm/shared/app/config/wcmservices/PersonalizationService.properties
<portal_root>/wcm/prereq.wcm/wcm/config/templates/shared/app/config/wcmservices/PersonalizationService.properties
<portal_root>/pzn/prereq.pzn/properties/config/services/PersonalizationService.properties (example file)
<portal_root>/wcm/shared/app/config/wcmservices/PersonalizationService.properties
Now that right file is selected the following items need to be changed:
To disable visibility rule caching rulesEngine.attributeBasedAdmin.enableCaching=false. This will disable the visibility rule cache only.
DO NOT disable general caching by setting rulesEngine.cache.enabled=false. This will disable the caches of the data, but not visibility rule caching.
For more information about settings and caching settings please refer to Best Practices for using Personalization (http://www-10.lotus.com/ldd/portalwiki.nsf/dx/personalization-best-practices) and the information center.
API
PznTransformationModel class, handles the visibility rule caching API. There are two main methods for invalidating the visibility rule caches invalidate(javax.servlet.http.HttpServletRequest request) and invalidate(javax.servlet.http.HttpServletRequest request, java.lang.String rule). They show up in many different ways. The methods are used for invalidating all the visibility rule or just for a single rule. This will only invalidate the visibility rule cache, not the cache which the visibility is may be based on.
Example for invalidating visibility rule cache.
PznTransformationModel.invalidate(request);
PznTransformationModel.invalidate(request,”/testViz”);
The first line will invalidate all the visibility rule that were used with the request object. The second line just invalidate the cache for the /testViz rule.
Please refer to the JavaDoc API for more information.