Java Reference
In-Depth Information
Chapter 17. Controlling Concurrent Access to Entity
Data with Locking
This chapter details how to handle concurrent access to entity data, and the locking
strategies available to Java Persistence API application developers.
The following topics are addressed here:
• “
Overview of Entity Locking and Concurrency
”
on page
297
• “
Lock Modes
” on page
299
Overview of Entity Locking and Concurrency
Entity data is
concurrently accessed
if the data in a data source is accessed at the same time
by multiple applications. Special care must be taken to ensure that the underlying data's in-
tegrity is preserved when accessed concurrently.
When data is updated in the database tables in a transaction, the persistence provider as-
sumes the database management system will hold short-term read locks and long-term
write locks to maintain data integrity. Most persistence providers will delay database writes
until the end of the transaction, except when the application explicitly calls for a flush (that
is, the application calls the
EntityManager.flush
method or executes queries with
the flush mode set to
AUTO
).
By default, persistence providers use
optimistic locking
, where, before committing changes
to the data, the persistence provider checks that no other transaction has modified or
deleted the data since the data was read. This is accomplished by a version column
in the database table, with a corresponding version attribute in the entity class. When
a row is modified, the version value is incremented. The original transaction checks
the version attribute, and if the data has been modified by another transaction, a
javax.persistence.OptimisticLockException
will be thrown, and the ori-
ginal transaction will be rolled back. When the application specifies optimistic lock modes,
the persistence provider verifies that a particular entity has not changed since it was read
from the database even if the entity data was not modified.
Pessimistic locking
goes further than optimistic locking. With pessimistic locking, the per-
sistence provider creates a transaction that obtains a long-term lock on the data until the
transaction is completed, which prevents other transactions from modifying or deleting the
data until the lock has ended. Pessimistic locking is a better strategy than optimistic locking
when the underlying data is frequently accessed and modified by many transactions.
