You should still think carefully about what it is you are trying to do. If you just catch the optimistic locking exception, and automatically reload and save, then you are ensuring the second user's change overwrites the first. The second user will never see the first user's change. That's not really optimistic locking at all. Even if you merge the two sets of changes, merging is tricky in all but the most trivial of cases.
More usually, optimistic locking involves *informing* the second user : "Another user has changed this record - please review their changes and try again" - this guarantees that you won't get merge collisions or other surprises. Be warned - much pain and trauma has been experienced in the past by people trying to automatically manage simultaneous changes in an automated way. The best answer is usually to say "why do you really want to do this?" - Korny On Thu, Nov 18, 2010 at 6:29 PM, Chris Mayan <chris.ma...@gmail.com> wrote: > SOLVED! > > Thanks Mikel for sending me in the right direction - I ended up finding a > pure rails way of doing it... (i'm switching search engines I think). > > The solution for anyone else interested is "Optimistic Locking" which by > default gets turned on on any models with a column that contains an integer > column called "lock_version" (which you initialise to 0 and leave alone > thereafter as AR will manage it then). > > Then when 2 different processes tries to update the table it will check the > lock version sequence number and it will realise it is working with a stale > version (as another process has updated it) and thus will throw an exception > (ActiveRecord::StaleObjectError), where then you can call .reload(), before > you try to save again, more effeciently. > > Brilliant... thanks :) > > Cheers > Chris > > > On Thu, Nov 18, 2010 at 6:05 PM, Mikel Lindsaar <raasd...@gmail.com>wrote: > >> On 18/11/2010, at 5:47 PM, Chris Mayan wrote: >> > Question: How on earth do you make Active Record model objects be multi >> thread / multi process safe, so that when an attribute is changed in one >> process (such as from a delayed job) whilst another process (such as a user >> / web server process which has loaded / mapped the same db row in question >> as an AR model object), access the attribute, will automatically uses the >> new modified attribute value... _without_ having to call model.reload >> manually? >> >> You can't... well... you can... but you have to call reload somewhere. >> >> The way this is handled best is using record locking in conjunction with >> database transactions which provides access to row and table locking. >> >> Then while you are doing the update, check to make sure that the record >> has not already been updated before performing your action, all within a >> transaction. >> >> Hope that nudges you in the right direction. >> >> >> Mikel Lindsaar >> http://rubyx.com/ >> http://lindsaar.net/ >> >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To post to this group, send email to rails-ocea...@googlegroups.com. >> To unsubscribe from this group, send email to >> rails-oceania+unsubscr...@googlegroups.com<rails-oceania%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to rails-ocea...@googlegroups.com. > To unsubscribe from this group, send email to > rails-oceania+unsubscr...@googlegroups.com<rails-oceania%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > -- Kornelis Sietsma korny at my surname dot com http://korny.info "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of" -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-ocea...@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
