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 <[email protected]> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<rails-oceania%[email protected]> > . > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
