IBM WEBSPHERE 6.1.X - Manual (Page 64)

5 9
W E B S P H E R E P O R T A L V 6 . 1 T U N I N G G U I D E
admit-threshold properties 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 -1 indicates 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.