The document says “This locking mechanism will function inside a single Ruby process. To make it work across all web requests, the recommended approach is to add lock_version as a hidden field to your form” but I don’t think this is true. The SQL statement has a WHERE clause that restrict updates only to the row the current ruby process/thread knows about. Therefore, even in a cluster of rails servers this scheme would work as long as ActiveRecord checks the number of rows updated to ensure it’s 1 (it does).
It depends on how is the application using the lock.
One use case is to load a record, do something with it, and save it.
Optimistic locking here would detect a race condition where some other code
changed the same record meanwhile. That's the scenario the docs refer to
when talking about the locality of the lock.
Another use case is to detect race conditions across web requests. You use
this mechanism when last-one-wins is not a good conflict resolution
mechanism.
Typical scenario is an edit action. The application stores the lock version
of the record as it is being presented to the user in a hidden field of the
form. When the user submits the form (think 2 minutes later), the
controller fetches the record and sets the lock version to the one in the
hidden field before saving.