Locking in JPA

If  our data has concurrent access   , then some kind of locking mechanism should be there to prevent data corruption.JPA supports two types of locking mechanisms. This chapter is discussing about  the various locking mechanisms in JPA as of JPA2.0.

Locking in JPA

There are  two locking strategies supporting by JPA.

They are :

  • Optimistic Locking
  • Pessimistic Locking

a)Optimistic Locking

Optimistic locking is the most common style of locking mechanism.By default ,Optimistic locking mechanism is using by all persistence providers. For optimistic locking the entity should have a version attribute. The type of the field  is preferably int. The attribute should be annotated with @Version or should be specified using  element  in case of XML mapping.The version attributevalue  will be automatically changing by the JPA provider at each commit. Before each commit JPA  checks for the version value . If a mismatch  occurs between the version values in the updated object and existing one in the database , then OptimisticLockException will be thrown and the original transaction will be rolled back.

Consider an example:- Suppose one user accessed an object and updating it. Assume the version value is 1.During this time ,assume another user accessed the same object , edited and committed.So this commit will change the version field value in database automatically .Suppose now the database row contains 2 as version value. Now the first user is  trying to commit the updated  object. So the commit operation will check for version attribute. Here the version numbers are different . So the exception will be thrown and transaction will be rolled back. We can catch the exception and can handle appropriately.

b)Pessimistic Locking

In case of pessimistic locking , the persistence provider makes a transaction which obtains a lock on the data it is handling till the end of the transaction.So other transactions cannot modify the data till the lock released.

The lock() method of EntityManager is using for pessimistic locking.

Example:entitymanager.lock(student, LockModeType.PESSIMISTIC_READ);

The lock request mode can be either Pessimistic Read(LockModeType.PESSIMISTIC_READ needs to be passed as argument) or Pessimistic Write (LockModeType.PESSIMISTIC WRITE needs to be passed as argument ) or Pessimistic Increment (LockModeType.PESSIMISTIC_FORCE_INCREMENT needs to be passed as argument)

The lock() method should be called from an active transaction. Otherwise TransactionRequiredException will be thrown.

Pessimistic Locking Timeouts

The maximum time the persistence provider need to get the lock may be specified using the property javax.persistence.lock.timeout. If lock is not acquired within this time , LockTimeoutException will be thrown.

Lock Modes

Lock Modes can be specified to enhance the level of optimistic locking  or to enable the pessimistic locking.The LockModeType enum has the constants  to specify the lock modes.

  • NONE  -:No lock
  • OPTIMISTIC -: Obtains the optimistic read locks for all entities with version attribute.
  • OPTIMISTIC_FORCE_INCREMENT -: Obtains the optimistic read locks for all entities with version attribute and increments the version attribute value.
  • PESSIMISTIC_READ -: Obtains long term lock on the data.Other transactions can read the data, but cannot modify or delete the same data.
  • PESSIMISTIC_WRITE -: Obtains long term lock  on the data. Other transactions cannot read , or update or delete the same data.
  • PESSIMISTIC_FORCE_INCREMENT -: Obtains long term lock on the data and increments the version attribute. Other transactions  cannot update or delete the same data.
  • READ -: Synonym of OPTIMISTIC

See Related Discussions

JPA Overview

JPA Example – Insert/Read

find method in JPA example

JPA Update Example

JPA Delete EXample


JPQL Update Query Example

JPQL Delete Query


Overview to caching in JPA

JPA Mapping Schemes

One To One Mapping in JPA

One To Many mapping in JPA

Many To Many Mapping in JPA

Many To One Mapping in JPA