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.
otherwise simple accounting).
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.
for optimistic locking,
It can be quite handy to just mock save! and have it throw
StaleObjectError. depending on your code you may also be able to do
firstInstance = SomeModel.find 1
secondInstance = SomeModel.find 1
secondInstance.created_at_will_change! #or anything that will make the
save not be a no-op
secondInstance.save!
#do something with firstInstance (it is now stale)
Pessimistic locking is a little different - not much will change for
your code except that a select or a write may just block for a little
longer than usual. You should be prepared to handle whatever your
database does if it times out getting a lock or detects a deadlock.
This technique works well. I’m able to reimplement save (or save!) to
simulate pretty much any race condition I want to handle. I ended up
with something like this:
mock save to simulate another user getting there first.
sneaky_user = users(:brian)
ItemForSale.send(:define_method, :save) do
buyer = sneaky_user
raise ActiveRecord::StaleObjectError, “Boom!”
end