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.
