Related to #52768.
Related to #75456.
Ignoring intents, CockroachDB currently only supports the unreplicated lock durability. Consequently, FOR UPDATE locks are subtly best-effort; it is possible for a client to unknowingly lose a lock (violates mutual exclusion) and even still commit (violates isolation).
The best-effort nature of these locks is surprising for Serailizable transactions and a correctness hazard for Snapshot and Read Committed transactions.
We should implement the Replicated lock strength:
|
// Durability represents the different durability properties of a lock acquired |
|
// by a transaction. Durability levels provide varying degrees of survivability, |
|
// often in exchange for the cost of lock acquisition. |
|
enum Durability { |
|
option (gogoproto.goproto_enum_prefix) = false; |
|
|
|
// Replicated locks are held on at least a quorum of Replicas in a Range. |
|
// They are slower to acquire and release than Unreplicated locks because |
|
// updating them requires both cross-node coordination and interaction with |
|
// durable storage. In exchange, Replicated locks provide a guarantee of |
|
// survivability across lease transfers, leaseholder crashes, and other |
|
// forms of failure events. They will remain available as long as their |
|
// Range remains available and they will never be lost. |
|
Replicated = 0; |
|
|
|
// Unreplicated locks are held only on a single Replica in a Range, which is |
|
// typically the leaseholder. Unreplicated locks are very fast to acquire |
|
// and release because they are held in memory or on fast local storage and |
|
// require no cross-node coordination to update. In exchange, Unreplicated |
|
// locks provide no guarantee of survivability across lease transfers or |
|
// leaseholder crashes. They should therefore be thought of as best-effort |
|
// and should not be relied upon for correctness. |
|
Unreplicated = 1; |
|
} |
We should then address #100194.
Jira issue: CRDB-26577
Epic CRDB-26544