Configuring Session State Replication Across Clusters
6.2.4.3 Configuring Session State Replication Across Clusters
You can use a third-party replication product to replicate state across clusters, or you can allow WebLogic Server to replicate session state across clusters. The following configuration considerations should be kept in mind depending on which method you use: ■ If you are using a third-party product, ensure that you have specified a value for jdbc-pool, and that backup-cluster-address is blank. ■ If you are using WebLogic Server to handle session state replication, you must configure both the jdbc-pool and the backup-cluster-address. Table 6–2 Cluster Elements in config.xml Element Description cluster-type This setting must match the replication type you are using and must be consistent across both clusters. The valid values are man or wan remote-cluster-address This is the address used to communicate replication information to the other cluster. This should be configured so that communications between clusters do not go through a load balancer. replication-channel This is the network channel used to communicate replication information to the other cluster. Note: The named channel must exist on all members of the cluster and must be configured to use the same protocol. The selected channel may be configured to use a secure protocol. data-source-for-session-persistence This is the data source that is used to store session information when using JDBC-based session persistence. This method of session state replication is used to perform cross-cluster replication within a WAN. For more information, see Section 6.2.4.6.3, Database Configuration for WAN Session State Replication. session-flush-interval This is the interval, in seconds, the cluster waits to flush HTTP sessions to the backup cluster. session-flush-threshold If the number of HTTP sessions reaches the value of session-flush-threshold, the sessions are flushed to the backup cluster. This allows servers to flush sessions faster under heavy loads. inter-cluster-comm-link-health-check-interval This is the amount of time, in milliseconds, between consecutive checks to determine if the link between two clusters is restored. Failover and Replication in a Cluster 6-15 If backup-cluster-address is NULL, WebLogic Server assumes that you are using a third-party product to handle replication. In this case, session data is not persisted to the remote database, but is persisted locally.6.2.4.4 Configuring a Replication Channel
Parts
» Oracle Fusion Middleware Online Documentation Library
» Document Scope and Audience Guide to this Document
» What Are the Benefits of Clustering? What Are the Key Capabilities of a Cluster?
» Servlets and JSPs EJBs and RMI Objects
» Getting Connections with Clustered JDBC Failover and Load Balancing for JDBC Connections
» Pure-Java Versus Native Socket Reader Implementations
» Client Communication via Sockets
» How WebLogic Server Creates the Cluster-Wide JNDI Tree
» How WebLogic Server Updates the JNDI Tree Client Interaction with the Cluster-Wide JNDI Tree
» Load Balancer Configuration Requirements Load Balancers and the WebLogic Session Cookie
» Related Programming Considerations How Session Connection and Failover Works with a Load Balancer
» Round-Robin Load Balancing Weight-Based Load Balancing
» Transactional Collocation Optimization for Collocated Objects
» Methods of Configuring Clusters Load Balancing for JDBC Connections
» Using Replication Groups HTTP Session State Replication
» Connection with Load Balancing Hardware Failover with Load Balancing Hardware
» Configuration Requirements for Cross-Cluster Replication
» Configuring Session State Replication Across Clusters
» Clustering Objects with Replica-Aware Stubs
» Failover and JDBC Connections Understanding Server and Service Migration
» Migration Terminology Oracle Fusion Middleware Online Documentation Library
» Features That Use Leasing Leasing Versions
» Determining Which Type of Leasing To Use High-availability Database Leasing
» Non-database Consensus Leasing Leasing
» Preparing for Automatic Whole Server Migration
» Configuring Automatic Whole Server Migration
» Startup Process in a Cluster with Migratable Servers
» Automatic Whole Server Migration Process
» Manual Whole Server Migration Process Administration Server Role in Whole Server Migration
» Migratable Server Behavior in a Cluster Node Manager Role in Whole Server Migration
» Cluster Master Role in Whole Server Migration
» JMS-related Services JTA Transaction Recovery Service
» Custom Store Availability for JMS Services Default File Store Availability for JTA
» Best Practices for Targeting JMS when Configuring Automatic Service Migration
» Architecture Web Application Tiers
» Combined Tier Architecture De-Militarized Zone DMZ Load Balancer Proxy Plug-In
» No Collocation Optimization Firewall Restrictions
» Multi-Tier Proxy Architecture Proxy Architecture Benefits Proxy Architecture Limitations
» Proxy Plug-In Versus Load Balancer
» DMZ with Two Firewall Configuration
» Dynamic Cluster Address If you do not explicitly define a cluster address
» Configuration Roadmap Install WebLogic Server
» Starting a WebLogic Server Cluster
» Configure Node Manager Configure Load Balancing Method for EJBs and RMIs
» Sample web.xml This section contains a sample deployment descriptor file
» Accessing Applications Via the Proxy Server Ensure that applications clients will
» Configure Replication Groups Configure Migratable Targets for Pinned Services
» Migrating When the Currently Active Host is Unavailable Use this migration
» Configure Multicast Time-To-Live TTL Configure Multicast Buffer Size
» Cluster-Related Configuration Options Follow Usage and Configuration Guidelines
» Manual Migration of the JTA Transaction Recovery Service State Management in a Cluster
» Naming Considerations Administration Server Considerations
» Firewall Considerations Avoiding Problems
» Check the Server Version Numbers Check the Multicast Address Check the CLASSPATH Value
Show more