Implementation of a locking protocol which acquires locks by contacting the coordinator. Because the coordinator maintains all locks, no total order configuration is required.
CENTRAL_LOCK has all members send lock and unlock requests to a central coordinator. The coordinator has a queue for incoming requests, and grants locks based on order of arrival. To prevent all acquired locks from being forgotten when the coordinator crashes, setting num_backups lets the coordinator backup lock information to a number of backup nodes. Valid values for num_backups are 0 (no backup) to N-1, e.g. in a cluster of 4, we can have only 3 backup nodes.
Say we have a cluster of {A,B,C,D,E} and num_backups=1. A is the coordinator, and A updates all locks (and released locks) in B as well. When A crashes, everybody falls over to B for sending lock and unlock requests. B in turn copies all existing locks over to C and - when locks are acquired or released - forwards this information to C as well.
An alternative is also the {@link org.jgroups.protocols.PEER_LOCK} protocol.
@author Bela Ban
@since 2.12
@see Locking
@see PEER_LOCK