Question

I have searched through the posts in stackoverflow and I hope this is not a duplicate.

I am trying my hands on Optimistic locking for the first time, I am able to do it with spring managed LockModeType, but unable to define the LockMode myself

Following is the code example:

I am injecting persistence context using:

@PersistenceContext
private EntityManager entityManager;

1st approach: Using annotational transaction

@Transactional
    public void updateUserProfile(UserProfile userProfile) {
        entityManager.lock(userProfile, LockModeType.OPTIMISTIC); // 1*
        entityManager.merge(userProfile);
    }

Exception at 1: java.lang.IllegalArgumentException: entity not in the persistence context

2nd approach: Managing transaction

public void updateUserProfile(UserProfile userProfile) {
        entityManager.getTransaction().begin(); // 2*
        entityManager.lock(userProfile, LockModeType.OPTIMISTIC); 
        entityManager.merge(userProfile);
        entityManager.getTransaction().commit();
    }

Exception at 2: Not allowed to create transaction on shared EntityManager - use Spring transactions or EJB CMT instead

3rd approach: Since I got exception with shared entityManager, I also tried creating EntityManager from entityManagerFactory.

@Transactional
public void updateUserProfile(UserProfile userProfile) {
        EntityManager em = entityManager.getEntityManagerFactory().createEntityManager();
        em.getTransaction().begin();
        em.lock(userProfile, LockModeType.OPTIMISTIC);  // 3*
        em.merge(userProfile);
        em.getTransaction().commit();
    }

Exception at 3: entity not in the persistence context

In my application context, I am using org.springframework.orm.jpa.JpaTransactionManager for defining transactionManager and org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean for defining entityManagerFactory

Thanks in advance!

Answer 1

Conditions for locking a JPA entity:

1. you must be within a transactional context
2. the entity must be in a managed state (i.e. active within a persistence context.

You seem to be violating (2) – attempt to lock detached entity.

You could merge() earlier.

Important Points:

• If you modify an entity and run a transaction, and you have a version attribute in the entity, marked with @Version, then optimistic locking is automatically carried out at the granularity of the entity. The version attribute is updated and if it hasn’t already changed in the DB, then the write succeeds. This is the common simple locking case, where all writes to an individual entity are serialised to avoid corruption. If each entity/record can be treated independently, no need to set any LockMode as this is default behaviour. Have a close look at this option – I suspect this matches your simple requirements.

• If you have more complex processing and need to carry out reads or writes across a number of logically related entity instances, as a consistent coherent atomic operation, with all other writes blocked/isolated for the duration – then you need to set your own lock mode, as automated individual per-entity locks won’t work. You need to carefully design the set of entities that are read or written in a coherent fashion and manually design and implement your own manual locking solution- possibly picking a top-most entity in a relationship hierarchy to record the “global” lock for all the related ‘child’ entities (leveraging its @Version attribute).

• Any manual locking solution requires all DB writing logic to honour the lock. This means that other transactions that operate on the same entities, must understand your locking design and in fact, must attempt to take out your lock before writing. A lock which doesn’t cause various writes to block and serialise is in fact no lock at all.

• For optimistic locking, the exact timing for taking out the lock is flexible. The lock is not checked and written to the DB until the commit & flush operation occurs. So you can take out the lock any time from the start of the tx to the commit. For pessimistic locking the opposite is true – you must guard the critical region(s) of code as if your life depends on it. Usually pessimistic lockMode should be set as part of a em.find() or em.query that starts of the transaction – or if this is not possible because managed objects are already in memory, then you should do a em.flush() and em.refresh(PESSIMISTIC_WRITE)

=:-)