On Tuesday 19 May 2009, Frederick Cheung wrote: > On May 19, 11:24 am, Michael Schuerig <[email protected]> wrote: > > Rails gives you optimistic locking automatically for tables that > > have the requisite timestamp columns (updated_at). Pessimistic > > locking you have to do explicitly. As a guess, I'd say that > > pessimistic locking is only worth your and the database's effort if > > conflicts are likely. > > You mean lock_version (integer, default 0)
Yes, of course. > > At any rate, with both locking strategies you have to take into > > account the possibility of a conflict. With optimistic locking, you > > get an ActiveRecord::StaleObjectError exception in that case. I'm > > not sure about pessimistic locking, but I guess you'll get an > > indistinctive ActiveRecord::StatementInvalid exception. > > If you hold a lock then anyone trying to update/select that row will > wait until you release your lock (or until they give up waiting). And if they give up waiting that manifests itself in some kind of error/exception that needs to be handled. Locking out other readers (SELECT) through SELECT ... FOR UPDATE is the default locking mode used by ActiveRecord when :lock => true is used. Nevertheless, the mode can be explicitly specified to allow concurrent readers, but block writers. PostgreSQL: :lock => 'FOR SHARE' MySQL: :lock => 'LOCK IN SHARE MODE' Michael -- Michael Schuerig mailto:[email protected] http://www.schuerig.de/michael/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
