Hi Chris, There is only one way (that I am aware of) of keeping things in sync between different processes (and as a result even different machines). It is MagLev. Watch this: http://www.vimeo.com/1147409
But as other pointed, you'd better reconsider your design as there is no single programming language (maybe apart from SmallTalk) that does what you want. Regards, Dima http://ApproachE.com On 18 November 2010 17:47, Chris Mayan <[email protected]> wrote: > Hello, > > I've done a lot of bing searching on this (perhaps I should try googling > instead...) with no luck, so perhaps the oceania crew can help as I seem to > have a complete misunderstanding of how Rails Object-Relational Mapping is > supposed to work: > > 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? > (i.e. I would like Rails in the background to automatically call the > model.reload when it detects that another process has modified any part of > the underlying model's DB row mapping, which is more desirable then calling > model.reload programatically before every access as that seems just > insane...) > > Is this possible or have I misunderstood how rails does ORM? > > So a concrete example: > Assume you have an AR model "ARModel" with tables ar_model and a string > attribute "attr" which has a default of "unchanged". > > 0. Open 2 terminals > 1. Start ./script/consoles in each terminal > 2. Terminal_1: >> tst_ar_model = ARModel.find(1) > 3. Terminal_2: >> tst_ar_model = ARModel.find(1) > 4. Terminal_1: >> tst_ar_model.attr > "unchanged" > 5. Terminal_2: >> tst_ar_model.attr > "unchanged" > 6. Terminal_1: >> tst_ar_model.attr = "something different" > 7. Terminal_1: >> tst_ar_model.save! > 8. Terminal_1: >> tst_ar_model.attr > "something different" > 9. Terminal_2: >> tst_ar_model.attr > "unchanged" > 10. Terminal_2: >> tst_ar_model.attr_changed? > False > > # What would it take for this to reflect the updated attribute value > "something different" automagically? > > Of course it works if you call in Terminal 2 tst_ar_model.reload; > tst_ar_model.attr... but it seems rather nuts to have to call this on every > attribute access everywhere! > > I have tried config.threadsafe! (and it's deprecated > config.action_controller.allow_concurrency > = true) > I've even tried on a longshot attr_will_change! ... > > I am working with Rails 2.3.5 > > Is there something else I need to set or have I completely misunderstood > something? I understand that the 2 AR model objects are 2 separate objects, > but being mapped to the same underlying db table entry, should update > concurrently I would have thought, or, at least know that the underlying > table object has changed and is dirty via _changed? ... > > Thus shouldn't Rails ORM when you declare threadsafe mode detect that when > an underlying DB table entry has changed, ensure that every invocation of an > attribute access will know that it has been changed or is dirty and force a > reload (or a partial one if it is smart enough to detect only a certain > field change?) > > Thanks for your help :) > > -Chris > > -- > 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.
