14
.
11
.
2023
22
.
06
.
2023
Ruby on Rails
Backend
Ruby
Tutorial

A simple guide to pessimistic locking in Rails

Michał Łęcicki
Ruby Developer

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
  threads << Thread.new do
    service.call
  end
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.

Michał Łęcicki
Ruby Developer

Check my Linkedin

READ ALSO

Lazy Attributes in Ruby - Krzysztof Wawer

Lazy attributes in Ruby

14
.
11
.
2023
Krzysztof Wawer
Ruby
Software

Exporting CSV files using COPY - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Ruby
Ruby on Rails
Michał Łęcicki - From Celluloid to Concurrent Ruby

From Celluloid to Concurrent Ruby: Practical Examples Of Multithreading Calls

14
.
11
.
2023
Michał Łęcicki
Backend
Ruby
Ruby on Rails
Software

Super Slide Me - Game Written in React

14
.
11
.
2023
Antoni Smoliński
Frontend
Jarek Kowalewski - ILIKE vs LIKE/LOWER - Postgres Stories

ILIKE vs LIKE/LOWER - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby
Ruby on Rails
Postgresql

A look back at Friendly.rb 2023

14
.
11
.
2023
Cezary Kłos
Conferences
Ruby

Debugging Rails - Ruby Junior Chronicles

14
.
11
.
2023
Piotr Witek
Ruby on Rails
Backend
Tutorial

GraphQL in Ruby on Rails: How to Extend Connections

14
.
11
.
2023
Cezary Kłos
Ruby on Rails
GraphQL
Backend
Tutorial

Tetris on Rails

14
.
11
.
2023
Paweł Strzałkowski
Ruby on Rails
Backend
Frontend
Hotwire

EURUKO 2023 - here's what you've missed

14
.
11
.
2023
Michał Łęcicki
Ruby
Conferences

Easy introduction to Connection Pool in ruby

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Backend
Ruby
Tutorial

When crazy ideas bring great time or how we organized our first Conference!

04
.
12
.
2023
Alexander Repnikov
Ruby on Rails
Conferences
Visuality

Stacey Matrix & Takeaways - why does your IT project suck?

14
.
11
.
2023
Wiktor De Witte
Project Management
Business

A simple guide to pessimistic locking in Rails

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Backend
Ruby
Tutorial

Poltrax design - story of POLTRAX (part 3)

04
.
12
.
2023
Mateusz Wodyk
Startups
Business
Design

Writing Chrome Extensions Is (probably) Easier Than You Think

14
.
11
.
2023
Antoni Smoliński
Tutorial
Frontend
Backend

Bounded Context - DDD in Ruby on Rails

14
.
11
.
2023
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

The origin of Poltrax development - story of POLTRAX (part 2)

29
.
11
.
2023
Stanisław Zawadzki
Ruby on Rails
Startups
Business
Backend

Ruby Meetups in 2022 - Summary

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Visuality
Conferences

Repository - DDD in Ruby on Rails

14
.
11
.
2023
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Example Application - DDD in Ruby on Rails

14
.
11
.
2023
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

How to launch a successful startup - story of POLTRAX (part 1)

14
.
11
.
2023
Michał Piórkowski
Ruby on Rails
Startups
Business

How to use different git emails for different projects

14
.
11
.
2023
Michał Łęcicki
Backend
Tutorial