https://www.visuality.pl/posts/a-simple-guide-to-pessimistic-locking-in-rails

Our website uses cookies for analytics and services improvement. To
learn more check Privacy Policy X
 
Services Case studies People Open source Career Blog Contact
 
Hire us
[mobilelogo]
 
Hire us
[hamburger-]

  * Home
  * Services
  * Case studies
  * People
  * Career
  * Blog
  * Contact
  * Open source

A simple guide to pessimistic locking in Rails

Michal Lecicki

Software engineer

22 Jun 23

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.

Advanced stuff

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
  service.call
end
threads.each(&:join)

expect(invoice.payments.count).to eq 1 # this should fail without a lock

Summary

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.

Tweet

Subscribe to our blog!

Get updates about new blog posts published on our website.

Email Address [                    ]
[                    ]
[Subscribe]
Previous Post

Concurrency and parallelism in Ruby (Processes, Threads, Fibers and
Ractors)

How to achieve concurrency and parallelism in Ruby? There are a
couple of ways and I will describe these in the following article. It
only covers the usage of Ruby core and standard library modules.
Modern CPUs consist of multiple cores, so software developers can
benefit. Nowadays programming languages with concurrency features
support the usage of multi-cores. Ruby is no exception, let's see how
this it could be done.

Read me
Jan Grela

Software engineer

[white_logo]

We commit to your success in the digital world. We build web & mobile
apps. Our clients value high ownership, business-driven approach and
top engineering standards.

Tech Stack

Ruby on Rails
React.JS
Progressive Web Apps
Go

Services

Ongoing projects
Projects from scratch
UX/UI

Our office

Odolanska 56
02-562 Warszawa
Poland

Hire us

+48 22 307 12 05
contact@visuality.pl

Industries

HR Tech Software Development
Sports Tech Software Development
Booking Systems Software Development

Resources

Company presentation
UX/UI Portfolio
Case Studies
Blog
Open source

[facebook-8] [dribble-bd] [instagram-] [linkedin-0] [stackshare]
[github-e96] [youtube-df] [medium-6fb]
[ue-25b9f53]
Top Web Developers Clutch