Cache management considerations for portal farms
Because the server instances are independent, there is no coordination of dynamic cache content or invalidations of that content. It is possible, therefore, for changes made on one server to not be seen immediately on another server in the farm. For this reason, it is important to configure caches to expire within a reasonable amount of time to ensure updates are seen in a timely manner without compromising the benefit of caching.
- Portal caches
- Portal caches cover
portal configurations, such as navigation,
page layout, and access control. These are automatically configured
to expire although time varies by cache. In general, most updates
are seen immediately on a server where administrative changes are
made directly and/or when a user logs off and then back into WebSphere Portal.
In a farm of unique installations, since administrative actions are necessary against all servers and must be applied to all servers manually, expiration of the portal caches should not be a general concern.
For shared configurations, configuration changes will generally appear across the farm when their caches expire, or when individual servers are restarted. See the Caching topic in the Related information for additional details.
- Content caches
- Content caches require special attention. Content caches are updated when a content item changes either through authoring activity or syndication. In a farming scenario, one server is designated as the subscriber for content syndication. Syndication will update the cache on this server as normal. A content cache invalidation message bean must be deployed on servers in the farm, consuming messages from the subscriber server. By consuming content item update messages from the subscriber, the content caches on all servers can be kept in sync and up-to-date.