Enterprise Tech Tip: Locking and Concurrency in Java Persistence 2.0
By edort on Sep 29, 2009
One of the real success stories behind Java EE 5 is the Java Persistence API, know informally as JPA. The technology has been widely adopted and is recognized as the enterprise standard for Object/Relational (O/R) persistence.
However, one of the shortcomings of JPA 1.0 is that the only type of locking it supports is optimistic locking. Recall that locking is a technique for handling database transaction concurrency. When two or more database transactions concurrently access the same data, locking is used to ensure that only one transaction at a time can change the data.
There are generally two locking approaches: optimistic and pessimistic. Optimistic locking assumes that there will be infrequent conflicts between concurrent transactions, that is, they won't often try to read and change the same data at the same time. In optimistic locking, the objective is to give concurrent transactions a lot of freedom to process simultaneously, but to detect and prevent collisions. Two transactions can access the same data simultaneously. However, to prevent collisions, a check is made to detect any changes made to the data since the data was last read.
Pessimistic locking assumes that transactions will frequently collide. In pessimistic locking, a transaction that reads the data locks it. Another transaction cannot change the data until the first transaction commits the read.
The next release of JPA, JPA 2.0, which will be offered as part of Java EE 6, adds support for pessimistic locking. Using JPA 2.0, you can lock an entity either optimistically or pessimistically, depending on how often you think transactions will collide.
To learn about the new locking support in JPA 2.0, see the Tech Tip Locking and Concurrency in Java Persistence 2.0 by Carol McDonald.