IBM 6.1.X manual

admit-thresholdproperties do not apply to all cache implementations. In general, only caches that are not shared will use these properties. There are other properties that should not be modified unless specifically instructed to do so by IBM WebSphere Portal support.

enabled: The enabled property determines whether a cache is used or not. If a cache is not enabled, the property has a value of false, then no values are held by the cache and every cache lookup will return a null value. This property should only be modified for testing purposes, never in a production environment. The supported values are true and false and the global default value is true.

lifetime: The lifetime property determines the number of seconds an entry will exist in a cache. A cache no longer returns an entry once the entry has existed longer than the lifetime property. Cache entries can also be invalidated prior to reaching their lifetime due to explicit invalidation of the entry or Least Recently Used (LRU) eviction from the cache.

A value of -1indicates an infinite lifetime. This value should be used with caution since cache entries will only be invalidated programmatically. Infinite lifetimes are particularly discouraged with access control caches because:

￿In a cluster there can be rare occurrences when not all cache invalidation messages are processed on every node due to race conditions in the application server’s dynacache code. While the probability of this occurring is low, it can not be completely avoided with the current code base. Finite lifetimes allow these entries to be invalidated.

￿Finite lifetimes allow modifications made to roles, which have been externalized to an External Security Manager, to be reflected in role caches.

If updates to production environments are restricted to a well-defined staging process using XML Access, it is usually safe to use infinite lifetimes.

size: The maximum number of entries in a cache is limited by the size property. If this size limit is reached, entries are removed from the cache by an algorithm which usually includes 1) remove invalidated entries and entries which have exceeded their lifetime and 2) apply a LRU algorithm to the valid entries.

Any positive integer is allowed. Cache sizes have a direct impact on the memory requirements of your portal, specifically the demands on the Java heap. You should monitor and record the Java heap metrics and any performance impact when modifying the size of a cache.

shared: Cluster-aware caches are shared across the nodes of a cluster. These caches propagate invalidations of cache entries by using the WebSphere Application Server DistributedMap interface.

5 9

W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E