How to prevent race condition in Ruby on Rails applications?

Race conditions are always surprising, which can occur in production and are difficult to reproduce. They can cause duplication of records in the database. Most of the time the locking mechanism is taken care of by the Rails framework. Users don't have to manage it; especially optimistic locking using the lock_version column. In case of transactions and race around conditions, we can prevent these issues with Pessimistic Locking in ActiveRecord. It locks a record immediately as soon as the lock is requested(uses database row-level locking). Race conditions happen when two users read and update a record at the

Speed up time-sensitive database process in Rails applications using a Connection pool, Threads, and Arel

Sometimes dealing with DB processes in a Rails application consume a lot of time. Often there are a bunch of small and simple DB queries that go endless. For example, bulk insertions or bulk updates in tables. Dividing it into various background jobs is an idle solution. In a few scenarios, we can't prefer background jobs e.g. the change you apply, makes the existing data invalid. In this article, we will see how to complete a large set of DB queries under minutes which would otherwise take hours if not optimized. It's a better practice to create a rake