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. Maybe the docs could be better? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
