Suggested Pages

Wednesday, June 6, 2012

Optimistic Lock

Problem

A very common problem in a web application is when we have to change values in the DB after reading these values. Suppose the situation is: a user reads information on a flight and then he decides to book. A simple way to manage this situation can be the following:
  • Open transaction;
  • Read access to a record (information on a flight);
  • Write access to a record (book the flight);
  • Close transaction.
The main problem of managing this situation with one transaction is that you have to lock a record, causing performance problems for the application. In addition this solution does not take into account the waiting time of the user to book the flight. We need to use the isolation level REPEATABLE_READ in order to avoid the possible lost update anomalies.

Solution

A known solution to the above problem is to use an optimistic locking technique, that permits to set a lower isolation level such as READ_COMMITTED. The optimistic locking technique is the following:
  • Open transaction;
  • Read access to a record (information on a flight);
  • Close transaction;
  • Keep a copy of the record;
  • Open a transaction
  • Read the record to be modified and, if the contents of the record read coincides with the original copy previously saved, then you can update otherwise the user will be informed of the impossibility to update.
This approach is a good practice when the total number of database accesses is higher than the total number of anomalies.
The transaction is used only for the time necessary to update the record.
In the practice this technique can be performed using a match based on the version or the timestamp as described below.

Optimistic lock with timestamp

If the object is very complex, in order to decide if you have to update a record, to many fields must be checked. To overcome this drawback, it's a common practice insert an extra field in each record . This field can be a timestamp used to keep track of the last update for that record. If the read timestamp coincides with the original copy previously saved, you can proceed to update the row.

JPA optimistick lock with @Version

In JPA you can use @Version annotation to perform an optimistic strategy. You can apply @Version to a numeric or data type. MyBean.java
@Entity
public class MyBean implements Serializable{
 ...
  @Id
  @Column
  private int id;

  @Version
  @Column
  private int version;

}
Suppose that two transactions will retrieve an entity with the same internal state from the DB and try to update it. The first transaction that is going to commit, will make a match between the version id of the database entity and the version id of the modified entity.The version id wil be the same so the transaction will commit and update the version id successfully.
The second transaction will find the version id with an higher value in the DB, so an OptimistickLockException will occur.
I'll speak about this exception in a next post.

No comments :

Post a Comment

Suggested Pages