Why Locking is required?
When two concurrent users try to update database row simultaneously, there are absolute chances of losing data integrity. Locking comes in picture to avoid simultaneous updates and ensure data integrity.
Types of Locking
There are two types of locking, Optimistic and Pessimistic. In this post optimistic locking is described with example.
There are two types of locking, Optimistic and Pessimistic. In this post optimistic locking is described with example.
- Optimistic Locking: This locking is applied on transaction commit. If entity (database row) is fetched by two users simultaneously, where first user updates and commits the row and second user tries to update row with an old version. Second user will get an exception as row is already updated and version is changed. A version number is associated for entity object to achieve optimistic locking. Whenever entity object is changed, its version number is automatically increased by one. If any transaction is performed on older version of entity, transaction is failed and application throws optimistic locking exception.
- Pessimistic Locking: Pessimistic locking explicitly restricts shared resources until the transaction completed. To get more detail about pessimistic locking refer this link .
How to Implement Optimistic Locking in JPA 2.0?
Let’s take an example; there are two Tables Company and Employee:
Table: Company
| ||||
Company_Id
|
Company_Name
|
Address
|
Survey_Sequnce
|
Version
|
1
|
AirTel
|
xyz
|
110
|
20
|
2
|
Reliance
|
abc
|
230
|
40
|
Table: Employee
| |||
Employee_Id
|
Employee_Name
|
Company_Id
|
Employee_Survey_No
|
1
|
Narendra
|
1
|
111
|
2
|
Vinay
|
1
|
112
|
3
|
Ranu
|
2
|
231
|
4
|
Rinku
|
2
|
232
|
Whenever, employee joins the company, he is asked to complete the company specific survey and after completion of the survey, 'Employee_Survey_No' is generated based on SURVEY_SEQUENCE from company table. To generate the survey number below steps are performed:
- Read the current sequence value specific to a company from company table (SURVEY_SEQUENCE)
- Increment the sequence count by 1
- Update the incremented value in company table (SURVEY_SEQUENCE)
- Use this incremented value to log into employee table as 'Employee_Survey_No'
In this use case, there are absolute chances that two parallel surveys are performed for same company, where two employees get same survey sequence. This scenario can be handled with the help of optimistic locking in JPA to avoid sequence update collisions for same company.
Let’s implement optimistic locking in JPA. JPA facilitates easy approach to handle optimistic locking.
Define the company entity and annotate version column property with @Version to enable optimistic locking for entity.
@Entity
@Table(name = "Company", schema = "MyDB")
public class Company {
private Long companyId;
private String companyName;
private String address;
private Long surveySequence;
private Long version;
@Id
@SequenceGenerator(name = "company_seq", sequenceName = "MyDB.company_seq")
@GeneratedValue(generator = "company_seq")
@Column(name = "COMPANY_ID", unique = true, nullable = false)
public Long getCompanyId() {
return companyId;
}
public void setCompanyId(Long companyId) {
this.companyId = companyId;
}
@Column(name = "COMPANY_NAME")
public String getCompanyName() {
return companyName;
}
public void setCompanyName(String companyName) {
this.companyName = companyName;
}
@Column(name = "ADDRESS")
public String getAddress() {
return address;
}
public void setAddress(String address) {
this.address = address;
}
@Column(name = "SURVEY_SEQUENCE")
public Long getSurveySequence() {
return surveySequence;
}
public void setSurveySequence(Long surveySequence) {
this.surveySequence = surveySequence;
}
@Column(name = "VERSION_ID")
@Version
public Long getVersion() {
return version;
}
public void setVersion(Long version) {
this.version = version;
}
}
|
Now create the company DAO method to fetch the survey sequence, increment and update incremented value into company table. As we have annotated company table column with @Version, JPA will take care about parallel company entity updates. If any transaction is performed with older version of entity, transaction is failed and this method will throw ‘OptimisticLockingFailureException’.
@Repository("companyDAO")
public class CompanyDAO {
public Long getNextSurveySequence(Long companyId) {
//Fetch company entity based on companyId
Company company = entityManager.findById(Company.class, companyId);
// Get the current survey sequence
Long surveySeq = company.getSurveySequence();
// Increment current sequence by 1
Long nextSurveySeq = surveySeq + 1L;
// Set new sequence in company entity
Company.setSurveySequence(nextSurveySeq)
// Update company with new sequence
entityManager.merge(company);
return nextSurveySeq;
}
}
|
Now create the service method to fetch the next survey sequence and handle optimistic locking exception. With maximum try count approach, you can retry data base operation for failed transactions.
@Service("companyService")
public class CompanyService {
public Long getNextSequenceForOrgId(Long companyId) throws Exception {
Long surveySequence = null;
//If any transaction is performed on older version of entity,
//transaction is failed and application throws the ‘OptimisticLockException’
for (int maxTryCount = 1; maxTryCount <= 3; maxTryCount++)
{
try {
surveySequence = companyDao.getNextSurveySequence(companyId);
break;
} catch (OptimisticLockingFailureException e) {
if (maxTryCount == 3) {
throw new Exception(e);
}
}
}
return surveySequence;
}
}
|
I hope this post helps you understanding and implementing optimistic locking with JPA. If you would like to share your thoughts on it, you are most welcome to comment.
Add a comment