Distributed locks and their limits
On This Lesson 4 topics
This lesson is planned. The outline below lists the topics it will cover. The full lesson has not been published yet.
In this lesson
know when a lock is safe and when it is only an optimization.
Planned topics
- A lock on a database row or a lock service (ZooKeeper, etcd) is useful for efficiency: avoid duplicate work.
- Unsafe scenario: instance A takes a lease, pauses (GC, network stall), the lease expires, B takes over, A wakes and still writes.
- A Redis
SET NX PXlock gives no safety guarantee under pauses and failover; do not use it alone for correctness. - Keep critical sections short and make the work idempotent.
- ShedLock provides database-backed single-run scheduling and is meant for efficiency, not strict mutual exclusion.
Draft outline details
Demonstration
a timeline: A acquires, A pauses, lease expires, B acquires and writes, A resumes and writes: both wrote.
Check your understanding
Why can a paused lock holder still do damage?
Show answer
It does not know its lease expired and writes anyway.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.