Sorry, yes you are correct that was a poor example and for that particular condition optimistic locking will validate correctly. On the other-hand conditions which use data from a reference but do not update that reference will still be able to race .e.g.
A fulfillment has fulfillment_line_item's which check that fulfillment.status != 'shipped' to validate a destroy on a fulfillment_line_item. This later case will validate on the stale fulfillment.status - but since only the fulfillment_line_item (not the fulfillment) is to be updated in such a transaction no error will be noted even if fulfillment.lock_version has changed (since no update to the parent would have been attempted). On Wednesday, January 6, 2016 at 4:27:46 PM UTC+8, Dieter wrote: > > You problem hast nothing todo with multiple dynos. This race condition can > occour as soon as you have multiple workers or threats (whatever your > server uses). But > its a normal issue and in my point of view you can handle it with > optimistic locking just fine. > > When you use optimistic locking rails prepends on every update und delete > (when you use object.destroy) a "AND locking_version=?", > object.locking_version. > > In your case when your #update transaction happens it's gets for instance > lock_version 1 and also your #delete transaction gets lock_version 1. > > Say the #delete transaction is faster so you will get an > ActiveRecord::StaleObjectError within you #update action or vice versa. > > You only have to handle the ActiveRecord::StaleObjectError. Without > handling this error the transaction will be rolledback (the slower one) > > But this is only true as long as you use a Isolation level which does not > read UNCOMMITTED data. > > This should be the default in most cases. > > You can test it this way (as long as you dont use rails identy map). > > # use same id for find > fulfillment1 = Fulfillment.find 1 > fulfillment2 = Fulfillment.find 1 > > fulfillment1.status = '...' > > fulfillment2.status = '...' > > > > fulfillment1.save! > > fulfillment2.save! # should raise an exception, take a look at the > generated SQL-Statement > > regards > dieter > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
