Recode Hive
How do you decide between optimistic and pessimistic locking in practice? #998
-
|
In systems built with languages like Java, Kotlin, Go, or C#, concurrency control often comes down to choosing between optimistic and pessimistic locking. Beyond textbook definitions, how do you decide which approach to use in real systems? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
The decision usually comes down to contention patterns and failure cost. I lean toward optimistic locking when: Conflicts are rare and short-lived. Retries are cheap and safe. The system favors throughput over strict latency guarantees. Pessimistic locking tends to make more sense when: Contention is high and predictable. The cost of retries is significant (e.g., complex transactions or external side effects). Latency variance is more problematic than raw throughput. In practice, optimistic locking often works well at smaller scales but degrades sharply once contention increases. At that point, pessimistic locking can produce more stable behavior, even if peak throughput is lower. The key is measuring contention early without real metrics, locking strategies are mostly educated guesses. |
Beta Was this translation helpful? Give feedback.
The decision usually comes down to contention patterns and failure cost.
I lean toward optimistic locking when:
Conflicts are rare and short-lived.
Retries are cheap and safe.
The system favors throughput over strict latency guarantees.
Pessimistic locking tends to make more sense when:
Contention is high and predictable.
The cost of retries is significant (e.g., complex transactions or external side effects).
Latency variance is more problematic than raw throughput.
In practice, optimistic locking often works well at smaller scales but degrades sharply once contention increases. At that point, pessimistic locking can produce more stable behavior, even if peak throughput is lower.
The key…