Wonderful Version annotation in JPA


So, let's begin! What does the Version annotation in JPA mean ?

In short, she is responsible for blocking in JPA. This annotation solves one of the problems that may arise as a result of parallel execution of transactions.

What problems may arise?

  1. Lost updates may occur in situations where two transactions running in parallel, trying to update the same data.
  2. Dirty reads occur when a transaction sees changes not yet made, made by another transaction. In such a case, a problem may arise due to the rollback of the second transaction, but the data have already been read first.
  3. Non-repeatable reads occur when the first transaction received data, and the second transaction made a change to them and successfully committed them, until the end of the first transaction. In other words, when, within the framework of a single transaction, the same request for receiving, for example, the entire table, returns different results.
  4. Phantom reading is a problem similar to non-repeatable reads, except that a different number of rows is returned.

Briefly about their decisions

  1. READ UNCOMMITED - solved using the Version annotation in JPA (this is what the article is about)
  2. READ COMMITED - allows you to read only committed changes
  3. REPEATABLE READ - a little more complicated here. Our transaction "does not see" changes to the data that it had previously read, and other transactions can not change the data that fell into our transaction.
  4. SERIALIZABLE - sequential execution of transactions

Each subsequent clause covers all previous ones; in other words, it can replace the solutions mentioned earlier. Thus SERIALIZABLE has the highest level of isolation, and READ UNCOMMITED is the lowest.


Version solves the problem with lost updates . How exactly, now and see.

Before proceeding to the code, it is necessary to stipulate that there are two types of locks: optimistic and pessimistic . The difference is that the former focus on situations in which multiple transactions try to change one field at the same time, occur extremely rarely, while others focus on the reverse situation. In accordance with this, there is a difference in their execution logic.

The optimisticwhen locks are committed to the database, the value of the field marked as version is compared at the time of receiving the data and at the moment. If it has changed, then there is some other transaction ahead of ours and managed to change the data, then in this case our transaction throws an error, and you need to restart it.

When using optimistic locks, a higher level of concurrency is ensured when accessing the database, but in this case, you have to repeat transactions that did not have time to make changes before others.

In the pessimistic, the same lock is applied immediately before the intended modification of the data to all the lines that this modification presumably affects.

And when usingpessimistic locks are guaranteed no contradictions during the execution of the transaction, by placing the rest in standby mode (but time is wasted), as a result of a decrease in the level of competitiveness.

LockModeType or how to set a lock

Blocking can be set by calling the EntityManager look method.

entityManager.lock(myObject, LockModeType.OPTIMISTIC);

LockModeType sets the blocking strategy.

LockModeType is 6 types (2 of which are optimistic and 3 of which are pessimistic ):

  1. NONE - no lock

Create our Entity
import lombok.Getter;
import lombok.Setter;
import javax.persistence.*;
public class MyEntity{
    private long version;
    private Integer id;
    private String value;
    public String toString() {
        return "MyEntity{" +
                "id=" + id +
                ", version=" + version +
                ", value='" + value + '\'' +

Create a class where all Callback methods will be implemented.
import javax.persistence.*;
public class OperationListenerForMyEntity {
    public void postLoad(MyEntity obj) {
        System.out.println("Loaded operation: " + obj);
    public void prePersist(MyEntity obj) {
        System.out.println("Pre-Persistiting operation: " + obj);
    public void postPersist(MyEntity obj) {
        System.out.println("Post-Persist operation: " + obj);
    public void preRemove(MyEntity obj) {
        System.out.println("Pre-Removing operation: " + obj);
    public void postRemove(MyEntity obj) {
        System.out.println("Post-Remove operation: " + obj);
    public void preUpdate(MyEntity obj) {
        System.out.println("Pre-Updating operation: " + obj);
    public void postUpdate(MyEntity obj) {
        System.out.println("Post-Update operation: " + obj);

import javax.persistence.*;
import java.util.concurrent.*;
// В этом классе создаем несколько потоков и смотрим, что будет происходить.
public class Main {
// Создаем фабрику, т.к. создание EntityManagerFactory дело дорогое, обычно делается это один раз.
    private static EntityManagerFactory entityManagerFactory =
    public static void main(String[] args) {
// Создаем 10 потоков(можно и больше, но в таком случае будет сложно разобраться).
        ExecutorService es = Executors.newFixedThreadPool(10);
        try {
// Метод persistFill() нужен для авто-заполнения таблицы.
            for(int i=0; i<10; i++){
                int finalI = i;
                es.execute(() -> {
// Лучше сначала запустить без метода updateEntity(finalI) так, чтоб java создала сущность в базе и заполнила ее. Но так как java - очень умная, она сама запоминает последний сгенерированный id, даже если вы решили полностью очистить таблицу, id новой строки будет таким, как будто вы не чистили базу данных(может возникнуть ситуация, в которой вы запускаете метод persistFill(), а id в бд у вас начинаются с 500).
            try {
                es.awaitTermination(10, TimeUnit.SECONDS);
            } catch (InterruptedException e) {
        } finally {
// Метод для получения объекта из базы и изменения его.
    private static void updateEntity(int index) {
// Создаем EntityManager для того, чтобы можно было вызывать методы, управления жизненным циклом сущности.
        EntityManager em = entityManagerFactory.createEntityManager();
        MyEntity myEntity = null;
        try {
// Получаем объект из базы данных по индексу 1.
            myEntity = em.find(MyEntity.class, 1);
// Вызываем этот sout, чтобы определить каким по очереди был "вытянут" объект.
            System.out.println("load = "+index);
// Эту строчку мы и будем изменять (а именно LockModeType.*).
            em.lock(myEntity, LockModeType.OPTIMISTIC);
// Изменяем поле Value, таким образом, чтобы понимать транзакция из какого потока изменила его.
            myEntity.setValue("WoW_" + index);
            System.out.println("--Greeter updated : " + myEntity +" __--__ "+ index);
        }catch(RollbackException ex){
            System.out.println("ГРУСТЬ, ПЕЧАЛЬ=" + myEntity);
    public static void persistFill() {
        MyEntity myEntity  = new MyEntity();
        EntityManager em = entityManagerFactory.createEntityManager();

First run with commented-out updateEntity method
Pre-Persistiting operation: MyEntity{id=null, version=0, value='JPA'}
Post-Persist operation: MyEntity{id=531, version=0, value='JPA'}
Все ожидаемо. Меняем id в методе find и идем дальше. 


This is an optimistic lock, well, this is so logical. As I wrote above, the value of the version field is compared; if it is different, an error is thrown. Check it out.

Loaded operation: MyEntity{id=531, version=0, value='JPA'}
load = 3
Loaded operation: MyEntity{id=531, version=0, value='JPA'}
load = 2
Pre-Updating operation: MyEntity{id=531, version=0, value='WoW_2'}
Pre-Updating operation: MyEntity{id=531, version=0, value='WoW_3'}
Loaded operation: MyEntity{id=531, version=0, value='JPA'}
load = 9
Pre-Updating operation: MyEntity{id=531, version=0, value='WoW_9'}
Loaded operation: MyEntity{id=531, version=0, value='JPA'}
load = 1
Pre-Updating operation: MyEntity{id=531, version=0, value='WoW_1'}
Post-Update operation: MyEntity{id=531, version=1, value='WoW_1'}
--Greeter updated : MyEntity{id=531, version=1, value='WoW_1'} __--__ 1
ГРУСТЬ, ПЕЧАЛЬ=MyEntity{id=531, version=0, value='WoW_2'}
ГРУСТЬ, ПЕЧАЛЬ=MyEntity{id=531, version=0, value='WoW_3'}
Loaded operation: MyEntity{id=531, version=1, value='WoW_1'}
load = 4
Pre-Updating operation: MyEntity{id=531, version=1, value='WoW_4'}
Post-Update operation: MyEntity{id=531, version=2, value='WoW_4'}
--Greeter updated : MyEntity{id=531, version=2, value='WoW_4'} __--__ 4
ГРУСТЬ, ПЕЧАЛЬ=MyEntity{id=531, version=0, value='WoW_9'}
Loaded operation: MyEntity{id=531, version=2, value='WoW_4'}
load = 0
Pre-Updating operation: MyEntity{id=531, version=2, value='WoW_0'}
Post-Update operation: MyEntity{id=531, version=3, value='WoW_0'}
--Greeter updated : MyEntity{id=531, version=3, value='WoW_0'} __--__ 0
Loaded operation: MyEntity{id=531, version=3, value='WoW_0'}
load = 6
Pre-Updating operation: MyEntity{id=531, version=3, value='WoW_6'}
Post-Update operation: MyEntity{id=531, version=4, value='WoW_6'}
Loaded operation: MyEntity{id=531, version=4, value='WoW_6'}
load = 5
Pre-Updating operation: MyEntity{id=531, version=4, value='WoW_5'}
Post-Update operation: MyEntity{id=531, version=5, value='WoW_5'}
--Greeter updated : MyEntity{id=531, version=4, value='WoW_6'} __--__ 6
--Greeter updated : MyEntity{id=531, version=5, value='WoW_5'} __--__ 5
Loaded operation: MyEntity{id=531, version=5, value='WoW_5'}
load = 7
Pre-Updating operation: MyEntity{id=531, version=5, value='WoW_7'}
Post-Update operation: MyEntity{id=531, version=6, value='WoW_7'}
Loaded operation: MyEntity{id=531, version=5, value='WoW_5'}
load = 8
Pre-Updating operation: MyEntity{id=531, version=5, value='WoW_8'}
--Greeter updated : MyEntity{id=531, version=6, value='WoW_7'} __--__ 7
ГРУСТЬ, ПЕЧАЛЬ=MyEntity{id=531, version=5, value='WoW_8'}

Observations: As can be seen from the results, threads 3, 2, 9, and 1 were the first to start loading; for them, the Pre-Update callback methods were called. The first stream where the Post-Update method was called was 1, as can be seen from the results, the field marked with the Version annotation has already been changed (increased by 1). Accordingly, all remaining threads 2, 3, 9 threw an exception. And so on. The result of executing value = WoW_7, version = 6. Indeed, the last Post-Update was at stream 7 with version = 6.


Works according to the same algorithm as LockModeType.OPTIMISTIC with the exception that after commit the value of the Version field is forcibly increased by 1. As a result, finally the field after each commit will increase by 2 (an increase that can be seen in Post-Update + forced increase) . Question. What for? If, after a commit, we still want to “conjure” over the same data, and we do not need third-party transactions that can break between the first commit and the closing of our transaction.

Important!If you try to change the data to the same, then in this case the Pre-Update and Post-Update methods will not be called. All transactions may crash. For example, we simultaneously read data from several transactions, but since the calls to the pre and post (update) methods take time, the transaction that tries to change the data (to the same ones) will be executed immediately. This will lead to an error of the remaining transactions.


Since the work of the remaining types of locks looks similar, so I will write about all at once and consider the result only on PESSIMISTIC_READ.

LockModeType.PESSIMISTIC_READ - pessimistic read lock.
LockModeType.PESSIMISTIC_WRITE - pessimistic write lock (and read).
LockModeType.PESSIMISTIC_FORCE_INCREMENT - pessimistic write lock (and read) with a forced increase in the Version field.

As a result of such locks, a long wait for locking may occur, which in turn can lead to an error.

The result for LockModeType.PESSIMISTIC_READ (not fully represented):
load = 0
Pre-Updating operation: MyEntity{id=549, version=5, value='WoW_0'}
Post-Update operation: MyEntity{id=549, version=6, value='WoW_0'}
Loaded operation: MyEntity{id=549, version=6, value='WoW_0'}
load = 8
Pre-Updating operation: MyEntity{id=549, version=6, value='WoW_8'}
Loaded operation: MyEntity{id=549, version=6, value='WoW_0'}
load = 4
Pre-Updating operation: MyEntity{id=549, version=6, value='WoW_4'}
ERROR: ОШИБКА: обнаружена взаимоблокировка
  Подробности: Процесс 22760 ожидает в режиме ExclusiveLock блокировку "кортеж (0,66) отношения 287733 базы данных 271341"; заблокирован процессом 20876.
Процесс 20876 ожидает в режиме ShareLock блокировку "транзакция 8812"; заблокирован процессом 22760.

As a result, threads 4 and 8 blocked each other, which led to an unsolvable conflict. Prior to this, stream 0 no one interfered with execution. The situation is similar with all threads up to 0.

Also popular now: