Configuring Session Binding Oracle Fusion Middleware Online Documentation Library

3-12 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache - Session Binding IAS: Select if the application is based on OC4J. Oracle Web Cache forwards routing information with each request to OC4J through Oracle HTTP Server. - Internal-Tracking: Select if the client does not support cookies and the application is not based on Oracle HTTP Server and OC4J. This option is intended for backward compatibility with earlier releases of Oracle Web Cache. Oracle Web Cache maintains an in-memory routing table, of which each entry maps a session ID to an origin server. The routing table is not shared among cluster nodes. If you select this option and you have a cache cluster configuration, then you must also bind at the load balancer layer.

5. Click Apply to submit changes.

6. Restart Oracle Web Cache. See Section 2.13 .

3.6 Configuring a Cache Cluster for Caches Using the Same Oracle WebLogic Server

To increase the availability and scalability of your Web site, you can configure multiple instances of Oracle Web Cache to run as members of a cache cluster. For more information about cache clusters, see Section 3.3 . To configure a cache cluster, you configure two or more Oracle Web Cache instances as cache cluster members, and specify properties for the cluster. A cache cluster uses one configuration that is synchronized from the current cache the cache to which your client browser is connected to all cluster members. The configuration contains settings that are the same for all cluster members as well as cache-specific settings for each cluster member. This section contains the following topics to aid you in configuring a cache cluster in a environment in which all the caches are associated with the same Oracle WebLogic Server. These instruction explain how to configure a cluster using Fusion Middleware Control, which requires all the cache members to use the same Oracle WebLogic Server: ■ Section 3.6.1, Configuration Prerequisites ■ Section 3.6.2, Understanding Failover Threshold and Capacity Settings ■ Section 3.6.3, Task 1: Add Caches to the Cluster and Configure Properties ■ Section 3.6.4, Task 2: Enable Tracking of Session Binding ■ Section 3.6.5, Task 3: Synchronize the Configuration to Cluster Members In addition, see the following information about configuring clusters: ■ Section 3.6.6, Removing a Cache Member from a Cluster ■ Section 3.6.7, Configuring Administration and Invalidation-Only Clusters If you have want to configure a cache cluster for a configuration in which the caches are associated with different Oracle WebLogic Servers, follow the instructions in Section 3.7 to use Oracle Web Cache Manager to configure the cluster.

3.6.1 Configuration Prerequisites

Because a cache cluster contains two or more instances of Oracle Web Cache, you must have two or more instances of Oracle Web Cache installed on one or more nodes before you configure a cache cluster. The instances must be the same version of Oracle Configuring High Availability Solutions 3-13 Web Cache. In addition, the respective passwords for the Oracle Web Cache administrator, and the invalidator user, invalidator, must be the same across the cluster members. If they are different, you must connect to the caches admin server and modify the administration password, as described in Section 5.2 .

3.6.2 Understanding Failover Threshold and Capacity Settings

To ease with configuration, take the time to understand the following key configuration settings for a cache cluster and its members: ■ Section 3.6.2.1, Failover Threshold for the Cache Cluster ■ Section 3.6.2.2, Capacity for Cache Cluster Members

3.6.2.1 Failover Threshold for the Cache Cluster

You set the failover threshold when you configure cache cluster properties. This setting reflects the number of allowed consecutive request failures before Oracle Web Cache considers another cache cluster member to have failed. In other words, Oracle Web Cache consecutively retries a failed member for certain number of times, before considering the cache-member as down. The number of times Oracle Web Cache is allowed to retry is termed as failover threshold. Oracle Web Cache considers a request to another cache cluster member to have failed if: ■ There are any network errors ■ The HTTP response status code is 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, or 504 Gateway Timeout, or less than 100. For each failed request, Oracle Web Cache increments the failure counter for that cluster member. This counter is kept separately by each cluster member. When a request is successfully processed by a cluster member, Oracle Web Cache resets the failure counter. When the failover threshold is met, Oracle Web Cache considers the cache cluster member to have failed. Oracle Web Cache recalculates the relative capacity of the remaining cache cluster members. It then reassigns ownership of cache content. When a cache cluster member is down, Oracle Web Cache starts polling the cache cluster member. It does this by sending requests to the ping URL you specify. When Oracle Web Cache receives a success response from the cache cluster member, it considers that cache cluster member to be up again. It recalculates the relative capacity of the cache cluster members and it reassigns ownership of cache content.

3.6.2.2 Capacity for Cache Cluster Members

When you configure a cache cluster member, you specify capacity for that member. Oracle Web Cache uses capacity in two different ways: ■ As the absolute capacity for the number of concurrent incoming connections to this cache cluster member from all other cache cluster members. The connections are used to receive requests for owned content from other cache cluster members. The number of connections are divided among the other cluster members. For example, in a three-cache cluster, if the capacity of Cache_A is 50, Cache_B can open 25 connections to Cache_A and Cache_C can open 25 connections to Cache_A.