In the Rails world, optimistic locking is relatively well known, while its pessimistic alternative is often overlooked. In this blog post, I will present how to effectively use pessimistic locking in Rails applications.
What is it?
Pessimistic locking works at the moment of retrieving the records from the database. One process blocks a particular record and others wait until it's unblocked. This ensures that a certain process will always use the newest version of the record (or raise an exception).
Pessimistic locking assumes that transaction conflicts occur frequently in the system. In such a situation optimistic locking wouldn't be much useful: it would cause irritating Stale Object errors too often. To address this challenge, a different approach is necessary.
The remarkable benefit of pessimistic locking is the fact that it doesn't affect the whole system. You don't have to change the database at all. Instead, you need to explicitly specify all areas which will utilize this technique. This way you have full control of which processes needs to care about locking. It's useful for fixing places with race conditions, without affecting other functionalities.
Show me the code
ActiveRecord::Base.transaction do # SELECT * FROM INVOICES WHERE id=? FOR UPDATE invoice = Invoice.lock.find(invoice_id) return unless invoice.status == 'new' invoice.create_payment invoice.update(status: 'paid') end
Selecting a particular invoice uses special SQL command:
SELECT ... FOR UPDATE. It "locks" the rows returned by
SELECT and prevents other processes from retrieving it until the transaction is done. At the same time, other places in the app could use the good old
Invoice.find(invoice_id) statement without worrying about locks.
It is possible to use database-specific locking by passing custom clauses to the
lock method, such as:
# raise an error if a record is already locked invoice = Invoice.lock("FOR UPDATE NOWAIT").find(invoice_id)
There is also an alternative method for locking individual records:
with_lock . In this scenario, all operations happening within the block are wrapped into the transaction.
invoice = Invoice.find(invoice_id) invoice.with_lock do (..) end
The general rule is: Always use pessimistic locking within a transaction. Theoretically, you can call
lock! method on records outside of it, but it doesn’t make sense and won’t simply work.
Testing pessimistic locking
Testing pessimistic locking is not trivial. To simulate the real conditions, many processes must attempt to retrieve a record simultaneously. This can be achieved by using some concurrency mechanisms, like ruby threads:
threads =  3.times do threads << Thread.new do service.call end end threads.each(&:join) expect(invoice.payments.count).to eq 1 # this should fail without a lock
There are certain scenarios when pessimistic locking is perfect. It's a valuable tool for resolving race conditions and maintaining data integrity. Use it when you don't want to introduce an extra
version column for optimistic locking. Or, when you need to fix a specific place in your Ruby on Rails app without affecting the rest of the system.