Features That Use Leasing Leasing Versions
7.3 Leasing
Leasing is the process WebLogic Server uses to manage services that are required to run on only one member of a cluster at a time. Leasing ensures exclusive ownership of a cluster-wide entity. Within a cluster, there is a single owner of a lease. Additionally, leases can failover in case of server or cluster failure. This helps to avoid having a single point of failure.7.3.1 Features That Use Leasing
The following WebLogic Server features use leasing: ■ Automatic Whole Server Migration—Uses leasing to elect a cluster master. The cluster master is responsible for monitoring other cluster members. It is also responsible for restarting failed members hosted on other physical machines. Leasing ensures that the cluster master is always running, but is only running on one server at a time within a cluster. For information on the cluster master, see Section 7.4.4.7, Cluster Master Role in Whole Server Migration. ■ Automatic Service Migration—JMS-related services, singleton services, and the JTA Transaction Recovery Service can be configured to automatically migrate from an unhealthy hosting server to a healthy active server with the help of the health monitoring subsystem. When the migratable target is migrated, the pinned service hosted by that target is also migrated. Migratable targets use leasing to accomplish automatic service migration. See Chapter 8, Service Migration. ■ Singleton Services—A singleton service is, by definition, a service running within a cluster that is available on only one member of the cluster at a time. Singleton services use leasing to accomplish this. See Section 8.8.1.1, Singleton Master. ■ Job Scheduler—The Job Scheduler is a persistent timer that is used with in a cluster. The Job Scheduler uses the timer master to load balance the timer across a cluster. Although you can use the non-database version, consensus leasing, with the Job Scheduler, this feature requires an external database to maintain failover and replication information.7.3.2 Leasing Versions
WebLogic Server provides two types of leasing functionality. Which one you use depends on your requirements and your environment. ■ High-availability database leasing—This version of leasing requires a high-availability database to store leasing information. For information on general requirements and configuration, see Section 7.3.4, High-availability Database Leasing. Note: Beyond basic configuration, most leasing functionality is handled internally by WebLogic Server. 7-4 Using Clusters for Oracle WebLogic Server ■ Non-database consensus leasing—This version of leasing stores the leasing information in-memory within a cluster member. This version of leasing requires that all servers in the cluster are started by Node Manager. For more information, see Section 7.3.5, Non-database Consensus Leasing. Within a WebLogic Server installation, you can use only one type of leasing. Although it is possible to implement multiple features that use leasing within your environment, each must use the same kind of leasing. When switching from one leasing type to another, you must restart the entire cluster, not just the Administration Server. Changing the leasing type cannot be done dynamically.7.3.3 Determining Which Type of Leasing To Use
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