What good is a best-effort exclusive lock, anyway?

An engineer explores why CockroachDB's SELECT ... FOR UPDATE is documented as a 'best-effort' lock that should not be relied upon for correctness under SERIALIZABLE isolation, unlike Postgres/MySQL where it provides a true exclusive lock. The explanation: CockroachDB already guarantees serializability through conflict detection and transaction restarts, so the lock isn't needed for correctness, but it exists purely as a performance optimization to reduce contention (e.g. thundering-herd ticket-sale scenarios) by making transactions wait their turn instead of all retrying simultaneously. The lock is implemented as a fast, unreplicated, in-memory mechanism that can be silently dropped on lease transfers or range splits/merges, even without any failure occurring.

Source: https://gaultier.github.io/blog/what_good_is_a_best_effort_exclusive_lock_anyway.html. 8 Sync News only summarizes and links out; content copyright belongs to the authors and original sources.