weblogic.cluster.singleton
Class ReplicatedLeasingBasis

java.lang.Object
  weblogic.cluster.singleton.SimpleLeasingBasis
      weblogic.cluster.singleton.ReplicatedLeasingBasis

All Implemented Interfaces:

LeasingBasis

public class ReplicatedLeasingBasis
extends SimpleLeasingBasis

LeasingBasis that delegates to replicated remote instances. Lampson and others advocate that high-performance, high-availability distributed systems utilize hierarchical lease managers. The reasoning is that consensus algorithms are generally slow and costly - this is true of both Paxos and our DatabaseLeasingBasis - and therefore cannot accomdate fast failover. Instead the primordial lease manager (PLM), is identified utilizing Paxos or some other consensus mechanism and long leases, and is used to manage short leases for some other master lease manager we shall call the hierarchical lease manager (HLM). The general principal is that the identification of the PLM is slow but does not rely on singleton state. The HLM is essentially singleton state that is managed through leases rather than consensus and can therefore be fast. The HLM owns the state for the duration of its lease. It may replicate that state elsewhere, or write it to stable storage, for fault-tolerance but it is still the owner for the duration of the lease. Other parties with some interest in the state agree to abide by the lease interval also avoiding split-brain syndrome.

In order for failover of the HLM to occur failure must be detected and a new HLM elected. The new HLM needs to have access to the old HLM's state. The HLM is leasing relatively quickly and so missed heartbeats can be detected relatively quickly. The new HLM can be elected by other candidate HLM's constantly trying to aquire the HLM lease from the PLM. The candidate HLM's can have access to the primary HLM's state through a replication framework.

In the caching scenario the HLM is not really a lease manager but instead contains partition location information. A client would manipulate a paritioned map by first inquiring of the HLM where a partition resides. Once the location information is known the partition is contacted directly. In order to provide fault tolerance the partition state needs to be synchronously replicated and the HLM needs to determine which copy is the copy-of-record. This can be achieved once again by the primary and secondary leasing against the HLM. This is exactly the scenario we just described for the HLM. One might wonder why we cannot collapse the partition leasing into the HLM and indeed we can, the issue is one of scalability.and fault-tolerance.

Let us consider the case of the partition owners leasing directly against the PLM first. Any cache operation first needs to determine the partition location and then perform the operation. Determining the partition location means that either (a) the caller contacts the PLM to get this or, (b) the partition table is replicated to all servers. (a) is clearly a single point-of-failure. The partition table would have to be maintained in stable storage and the failover time would equate to the server reboot time for the PLM. (b) is a non-sequitur, the state can be replicated, but it cannot be consulted since all copies are, apart from that of the PLM, not authoritative. For the replicated copies to be authoritative the consensus algorithm would have to be run on the partition table itself - a costly operation.

Let us now consider the case of the partition owners leasing against the HLM which in turn leases against the PLM. Partition location information would be determined by contacting the HLM. How does a server know where the HLM resides? In the first instance the server gets this from the PLM. This is not a lease, merely a bootstrap to the HLM. Once the HLM (and the HLM's secondary) is located a server does not need to contact the PLM again unless both the HLM and HLM secondary fail simultaneously. All well and good, but suppose the PLM fails instead. The master HLM's lease will expire and it will be unable to renew it. In this instance a failure detector can be used to determine the outcome of its current lease.

Failure detectors can be implemented in practice by having the failure detector probe each process regularly; an unresponsive process p is placed on the list and a broadcast message is sent to all processes (including p) announcing its death. If p is has not actually crashed, then it will eventually refute its death announcement. Chandra and Toueg show that this weak and unreliable model of failure detectors allows the consensus problem to be solved.

In our case it the master HLM should assume that the PLM has failed and announce it to interested parties. If the PLM has not failed then it will refute the claim, or if the PLM is not contactable by the master, but is contactable by the secondary then the secondary will refute the claim. In this case the master should relinquish its lease since the secondary will have already obtained the lease. If no-one refutes the claim then the master can continue to hold its lease until the consensus algorithm has elected a new PLM. For N HLM's we can tolerate N-1 failures. Thus if we want more reliability we need mor replicas.

BASIS_NAME

public static final String BASIS_NAME

See Also:

Constant Field Values

ReplicatedLeasingBasis

public ReplicatedLeasingBasis(String leaseType)
                       throws IOException

Throws:

IOException

getReplicatedMap

protected static Map getReplicatedMap(String leaseType)
                               throws IOException

Throws:

IOException