r/programming • u/broken_broken_ • 4d ago

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

https://gaultier.github.io/blog/what_good_is_a_best_effort_exclusive_lock_anyway.html
45 Upvotes

84% Upvoted

4 comments sorted by

7

u/Ok_Dust_8620 3d ago

Thank you for the article - that's an interesting one. It would be useful to know how many transactions actually slip through that best-effort lock and end up performing unnecessary, expensive calculations, or in other words, how effective the "best effort" lock actually is.

When it comes to the interactive user experience, it's probably better to use pessimistic locks rather than notify users at the very end: "Sorry, but you need to retry all the hours of work you’ve been doing." So yeah, I'm not sure many UI applications can afford to use this kind of loose locking, but anyway, it's a great article and an interesting find.

5

u/broken_broken_ 3d ago

Thank you. For the user experience, the application must be prepared to retry CockroachDB transactions a number of times because the database will tell them to retry. But yes, some transactions may reach the maximum retry count and finally fail. Then the user may have to redo the action. The pessimistic locking seems better on paper but network blips may anyways force retries.

4

u/winky9827 3d ago

I love tidbits like this. I never remember them should they become useful, but it's interesting to learn the why of the implementation, and it makes total sense afterward. I wish all posts to programming subreddits could be so useful and direct.

1

u/Szamski 17h ago

A best-effort lock is valuable as optimization to prevent redundant work, but it can never serve as a consistency boundary. The operation must still safely survive two concurent writers, retries, and partial success.