Each member of the cluster uses its own
LeaderOnlyLockManager which wraps a local
Locks manager.
The validity of local lock managers is synchronized by using a token which gets requested by each server as necessary
and if the request is granted then the associated id can be used to identify a unique lock session in the cluster.
The fundamental strategy is to only allow locks on the leader. This has the benefit of minimizing the synchronization
to only concern the single token but it also means that non-leaders should not even attempt to request the token or
significant churn of this single resource will lead to a high level of aborted transactions.
The token requests carry a candidate id and they get ordered with respect to the transactions in the consensus
machinery.
The latest request which gets accepted (see
ReplicatedTransactionStateMachine) defines the currently valid
lock session id in this ordering. Each transaction that uses locking gets marked with a lock session id that was
valid
at the time of acquiring it, but by the time a transaction commits it might no longer be valid, which in such case
would lead to the transaction being rejected and failed.
The
ReplicatedLockTokenStateMachine handles the token requests and considers only one to be valid at a time.
Meanwhile,
ReplicatedTransactionStateMachine rejects any transactions that get committed under an
invalid token.