This is a two part question. Which type of locking should I use (optimistic vs. pessimistic) and then how do I account for locking in my tests?
My scenario is essentially the purchase of a unique item where the first person to click "Buy" gets the item and everyone else is out of luck. As a single transaction, I need to determine whether the item has already been purchased; if so provide an error message, otherwise buy it. If I did not lock, race conditions may lead multiple people to think they were succesful (and it would make a mess out of my otherwise simple accounting). I'm leaning towards optimistic because: 1) my rails app is the only thing touching the DB, 2) I'm trying to remain agnostic on DB software for now, but 3) I don't really want a read-lock. Am I overlooking anything that might push me in the other direction? For testing, I'm trying to be a good TDD citizen, so exactly what test would cause me to write the logic to handle ActiveRecord::StaleObjectError? (Or if I go with pessimistic, the :lock => true option) Considering the record is located, updated, and saved by the same method I can't think of a good way to actually cause the race condition for a test. But common sense tells me it will happen frequently once I have multiple users interacting with the app. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
