On 19 November 2010 10:09, Mikel Lindsaar <[email protected]> wrote:
> On 19/11/2010, at 9:04 AM, Dmytrii Nagirniak wrote: > > On 19 November 2010 08:47, Korny Sietsma <[email protected]> wrote: > >> 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. >> > Yep. And this is how AR (basically most of ORMs) works by default - last > wins. Nothing to do with the locking. > Wondering why not just use a proper database transaction if atomicity is a > requirement? > > > Well as Korny was saying transactions and row locking won't help you if > both data sets are valid. > > But the main problem for Chris is that the data is being updated while calculations are in progress. To avoid having stale objects, the transactions can be used. Of course, merging is totally different thing and is way more complicated. But as far as I understand Chris needs to ensure that there are no stale objects in the middle of an action (not user's one but a system's). -- 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.
