It’s okay to make mistakes when you are up to building simple applications. But for mission critical applications like Banking/Payment Processors, you gotta be very careful and keep listening to seniors and experts in critical matters.

Lets say you are working on a feature to update the total amount deposited in a particular account. Simple code will do like

# just after amount is debited from payee's account
def credit_receiver_account(debited_amount)
  update_attribute :total_amount, total + debited_amount
end

What’s wrong with the code above?

Consider that the receiver account belongs to a conglomerate like google who keeps receiving payments every milliseconds. So, there is always chances that the variable total contains an older/obsolete data. This can be a chaotic situation. This happens because the ruby object corresponding to the database row can represent different values.

How to avoid such race condition?

Just like to stop the race you stop/pause all others and let only one to run, you will lock the data to maintain consistency.

There are two types of locking – optimistic and pessimistic

---

What is Optimistic Locking?

Optimistic locking allows multiple users to access the same record for edits, and assumes a minimum of conflicts with the data. It does this by checking whether another process has made changes to a record since it was opened, an ActiveRecord::StaleObjectError exception is thrown if that has occurred and the update is ignored.

Usage

Active Record supports optimistic locking if the lock_version field is present. Each update to the record increments the lock_version column and the locking facilities ensure that records instantiated twice will let the last one saved raise a StaleObjectError if the first was also updated. Example:

p1 = Person.find(1)
p2 = Person.find(1)

p1.first_name = "Michael"
p1.save

p2.first_name = "should fail"
p2.save # Raises an ActiveRecord::StaleObjectError

Optimistic locking will also check for stale data when objects are destroyed. Example:

p1 = Person.find(1)
p2 = Person.find(1)

p1.first_name = "Michael"
p1.save

p2.destroy # Raises an ActiveRecord::StaleObjectError

---

Using Pessimistic locking

# select * from accounts where id=1 for update
Account.lock.find(1)

Call lock('some locking clause') to use a database-specific locking clause of your own such as 'LOCK IN SHARE MODE' or 'FOR UPDATE NOWAIT'. Example:

Account.transaction do
  # select * from accounts where name = 'shugo' limit 1 for update
  shugo = Account.where("name = 'shugo'").lock(true).first
  yuko = Account.where("name = 'yuko'").lock(true).first
  shugo.balance -= 100
  shugo.save!
  yuko.balance += 100
  yuko.save!
end

Shorter Syntax

The race condition can be fixed using Pessimistic Locking technique using the locking feature of the Database. This technique not only protects from stale-object updates but also from concurrent updates(occurring almost simultaneously) in real-world (very rare though).

def credit_receiver_account(debited_amount)
  self.with_lock do
    update_attribute :total_amount, total_amount + debited_amount
  end
end