This is to avoid the race as described below:

1. Alice tries to get lock, generates a ts of TSa.
2. Alice got descheduled.
3. Bob tries to get lock, generates a ts of TSb. Note: TSb > TSa.
4. Bob successfully grabs the lock sets the state to 2 ("locked") for all 3 config server.
5. Bob is done and tries to unlock the lock.
6. Bob finished unlocking the first config server and set the state to 0 ("unlocked")
7. Alice comes back again, sees that lock state of first config server is 0, proceeds to attempt to acquire the lock by sending the update to set state to 1 ("transition to lock") to all 3 config server.
8. Alice finds out that the update did not apply successfully to all config server (this is because the update query only matches the first config, who has the state at 0).
9. Alice goes to the tournament round and compares the ts field of the lock document in all config servers.
10. Alice sees that TSb > TSa, so she backs out of the tournament round.
11. Bob proceeds on unlocking the locks in the 2 other config servers.
12. The final state of the lock document ends up with:

server1: state: 1, ts: TSa
server2: state: 0
server3: state: 0

Once it ends up with this state, this lock can never be taken back again, until Alice's process stops pinging.