Data Consistency by Locking: Rails Way

In Databased based application data consistency is an important issue. Data inconsistency might occur when more than one users are updating the same model at the sametime. For example you have a model Book. The model has this properties:

- id
- title
- writer

There is one Book with this properties:
- id => 1
- title => "My book title"
- writer => "Mr. Y"

User1 selects a Book (id=1) in to edit and then User2 selects the same Book (id=1) to edit. Now the User1 changed the value of writer to 'Zahid' and saved it. In the database following update query will be executed:


UPDATE books SET title = 'My book title', writer = 'Zahid' WHERE id = 1


And the User2 changed the value of title to 'Updated Title' and saved it. In the database following update query will be executed:


UPDATE books SET title = 'Updated Title', writer = 'Mr. Y' WHERE id = 1


As a result the update done by User1 will get lost.


This is a common problem and there are two different solutions of this problem:
1) Pessimistic Locking
2) Optimistic Locking


Pessimistic Locking:

Pessimistic locking functionality is provided by the database. This locking happens at the database level. In this locking you have to lock the record while selecting the record to update. You can lock a record while updating by using "FOR UPDATE" with the "SELECT" query [NOTE: There are some other locking clause except "FOR UPDATE" and for that read the database documentation].
And the rails ways to do this locking are:

1) while selecting use :lock => true
2) use lock! method of a model that is already selected


Example:

Book.transaction do
book = Book.find(1, :lock=> true)
book.writer = 'Zahid'
book.save!
end


This will lock the book record (id = 1) through out the specified transaction and prevent updates of this record during this time. But if the model is already selected and then you want to lock it for update in that case you can lock the model with lock! method:


book = Book.find(1)
book.lock!


The problem with Passimistic Locking is, if a user select a book to update it and then forget about it or the locking time gets extended for any reason then if there is any other call to update this model then the second call will just HANG, no error will be raised.


Optimistic Locking:


This is a tricky way of confirming data consistency but not locking the record. As here no record is locked so there is no chance of HANG. In this method a new column is added to a table that column contains a version of the record. Unlike Pessimistic Locking the protection is provided at the application level instead of database level.


Lets say the column name is lock_version and the default value is 0. So when the User1 select a Book to update then
- the lock_version for this model is 0


User2 selects the same Book to update and this again
- the lock_version for this model is 0


If any of the user update the Book model then:
- save the udpated model
- the lock_version is incremented by one

Then if the other user wants to save his data the updated record will have lock_version = 0 and in the table the record has lock_version = 1 that means there is dirty data. In that case we can write code so that the second user will not be able to save the dirty data. He will need to refetch the data and update it.

In rails this support is already given with ActiveRecord. What you will need is only to add an extra column lock_version [aka. 'magic column'] with default value = 0 in the 'books' table. When updating the framework will confirm that the updating record has the same value as when the model was first read from database. If the values are equal then it will allow to update the record and then increment the value of lock_version column. Otherwise it will raise ActiveRecord::StableError.


You can deactivate this behavior by setting ActiveRecord::Base.lock_optimistically = false. If you want to override the name of the lock_version column you will need to invoke the set_locking_column method.