JPA 2.0 lock mechanism and jpa2.0 Lock Mechanism

JPA 2.0 lock mechanism and jpa2.0 Lock Mechanism

A lock is a technique used to process database transaction concurrency. When two or more database transactions concurrently access the same data, the lock ensures that only one transaction can modify the data at the same time.

There are usually two lock Methods: Optimistic lock and pessimistic lock. Optimistic locks hold that there are few conflicts between multiple concurrent transactions, that is, they do not often read or modify the same data at the same time. In optimistic locks, the goal is to allow concurrent transactions to be processed at the same time, rather than discovering or preventing conflicts. Two transactions can access the same data at the same time. To prevent conflicts, You need to perform a check on the data to check any changes that have occurred since the last data read.

Pessimistic locks hold that transactions often conflict with each other. In pessimistic locks, transactions that read data lock the data, and other transactions cannot modify the data before the previous transaction is committed.

JPA 1.0 only supports optimistic locks. You can use the lock () method of the EntityManager class to specify the lock mode value, which can be READ or WRITE, for example:

EntityManagerem = ...;

Em. lock (p1, READ );

For the READ lock mode, the JPA Entity Manager locks the entity before the transaction is committed. It checks the version attribute of the entity to determine whether the entity has been updated since the last READ. if the version attribute is updated, the Entity Manager throws an OptimisticLockException and rolls back the transaction.

For the WRITE lock mode, the Entity Manager performs the same optimistic Lock operation as the READ lock mode, but it also updates the version column of the entity.

JPA 2.0 adds six new lock modes, two of which are optimistic locks. JPA 2.0 also allows pessimistic locks and adds three types of pessimistic locks. The 6th lock modes are unlocked.

The following are two new optimistic lock modes:

1. OPTIMISTIC: it is the same as the READ lock mode. JPA 2.0 still supports the READ lock mode, but it is clear that OPTIMISTIC is recommended in new applications.

2. OPTIMISTIC_FORCE_INCREMENT: it adopts the same WRITE lock mode as the WRITE lock mode. JPA 2.0 still supports the WRITE lock mode, but it is clear that OPTIMISTIC_FORCE_INCREMENT is recommended in new applications.

The following are three new pessimistic lock modes:

1. PESSIMISTIC_READ: as long as the transaction reads the entity, the Entity Manager locks the entity until the Transaction Completes the lock. This lock mode is used when you want to query data using repeated read semantics, in other words, when you want to ensure that the data is not modified during continuous read, this lock mode will not prevent other transactions from reading data.

2. PESSIMISTIC_WRITE: the Entity Manager locks the entity as long as the transaction updates the entity. This lock mode forces the transaction to be serialized by modifying the Entity Data, this lock mode is used when multiple concurrent update transactions fail to update.

3. PESSIMISTIC_FORCE_INCREMENT: when the transaction reads the entity, the Entity Manager locks the entity. When the transaction ends, the version attribute of the entity is added even if the entity is not modified.

You can also specify the new lock mode NONE. In this case, no lock occurs.

JPA 2.0 also provides multiple methods to specify the lock mode for entities. You can use the lock () and find () Methods of EntityManager to specify the lock mode. In addition, the EntityManager. refresh () method can restore the status of the entity instance.

The following code shows a pessimistic lock using the PESSIMISTIC_WRITE lock mode:

// Read

Part p = em. find (Part. class, pId );

// Lock and refresh before update

Em. refresh (p, PESSIMISTIC_WRITE );

Int pAmount = p. getAmount ();

P. setAmount (pAmount-uCount );

In this example, it first reads some data, then applies the PESSIMISTIC_WRITE lock, and CALLS EntityManager before updating the data. the refresh () method. When a transaction updates an entity, PESSIMISTIC_WRITE locks the entity and other transactions cannot update the same entity until the previous transaction is committed.

JPA 20 optimistic lock exception,

Check the transaction control. This exception is not well controlled by the transaction.
 
How does jpa20 install the jpa framework used in the current project? How can I change it to jpa2?

It's hard for you to answer this question ......
JPA2.0 only regulates the underlying layers used by your JPA? HIBERNATE?
Under normal circumstances, you only need to replace the original JPA1.0 and underlying implementation with 2.0.
We recommend that you use HIBERNATE to support JPA2.0.