Enabling Search Keys for Invalidations

7-34 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache

7.10.2 Propagation of Invalidation Messages

Propagation of invalidation messages from one Oracle Web Cache server to another occurs in the following deployments: ■ Cache cluster with multiple Oracle Web Cache servers ■ Cache hierarchy whereby one Oracle Web Cache server acts as an origin server to another Oracle Web Cache server

7.10.2.1 Invalidation in Cache Clusters

In a cache cluster, administrators can decide whether to propagate invalidation messages to all cache cluster members or to send invalidation messages individually to cache cluster members. When Oracle Web Cache propagates invalidation messages, the cache that received the invalidation request acts as the invalidation coordinator for that request. The coordinator propagates the invalidation messages to the other cluster members. The coordinator waits for responses from all cluster members. When the propagation completes, the coordinator returns a message to the sender that lists, for each cluster member, the cluster member name, the status of the invalidation request, and the number of objects invalidated. If any cluster member cannot be reached, Oracle Web Cache returns an error message and does not propagate the invalidation messages. During a cache cluster upgrade, you upgrade one cache cluster member at a time. The caches continue to respond to requests. However, because other cluster members have a different version of the configuration, the caches do not forward invalidation messages to those cache cluster members operating with a different version. Instead, if the requested object is not cached by that cache or by cluster members with the same version of the configuration, Oracle Web Cache forwards the request to the origin server. When the cache cluster members are not running the same version of Oracle Web Cache, you can still invalidate objects, and you can propagate the invalidation to other cluster members, but the invalidation message must originate from the cache that is operating with the earlier version of Oracle Web Cache. See the Oracle Fusion Middleware Upgrade Planning Guide for more information about upgrading Oracle Web Cache to 11g Release 1 11.1.1, including information about upgrading cache cluster members

7.10.2.2 Invalidation in Hierarchies

In a configuration with a hierarchy of Oracle Web Cache servers, a cache hierarchy , it is likely that content is cached on multiple servers. Figure 7–2 depicts a distributed cache hierarchy . A central cache is located in the United States office, and a remote cache is located in the Japan office. While the central cache stores content from an application Web server, the remote cache stores content from the central cache. In other words, the central cache acts as an origin server to the remote cache in Japan. The central cache uses the invalidator account name and password of the remote or subscriber Oracle Web Cache server. The invalidation request specifies the objects to invalidate, as well as the site host name of the objects. The site host name is compared with the IP address of the cache from which the invalidation request was propagated. If there is a match, the cache processes the invalidation request. Otherwise, the request is rejected. Invalidating Content 7-35 For automatic propagation of invalidation messages, Oracle Web Cache passes the encoded invalidator password in the page request between the central and remote cache during the hierarchy registration process. This HTTP traffic is susceptible to network sniffing. If the network is unprotected and insecure, configure HTTPS ports as follows: ■ Disable the default HTTP port and configure an HTTPS port in its place for the central cache. See Section 5.4.2 . ■ Disable the default HTTP port for invalidation and configure an HTTPS port in its place for the remote cache. See Section 5.5.1 . When an invalidation message is sent to the central cache to refresh content, the central cache automatically propagates the invalidation message to the remote cache in Japan to ensure consistency. Figure 7–2 Invalidating Content in a Distributed Cache Hierarchy To ensure that the central cache only invalidates its content, the remote cache checks the site host name specified in the invalidation message with the IP address of the central cache from which the invalidation message was propagated. If there is a match, the remote cache processes the invalidation request. Otherwise, the request is rejected. The site host name for the central and remote caches should be configured to be identical, making a mismatch unlikely. See Section 10.2 for instructions on configuring a cache hierarchy. Central Oracle Web Cache Application Server Invalidation Message Propagation Remote Oracle Web Cache Internet United States Japan