It is not intended that users spend much time worrying about locking strategies. It's usually enough to specify an isolation level for the JDBC connections and then simply let the database do all the work. However, advanced users may sometimes wish to obtain exclusive pessimistic locks, or re-obtain locks at the start of a new transaction.
Hibernate will always use the locking mechanism of the database, never lock objects in memory!
The LockMode
class defines the different lock levels that may be acquired
by Hibernate. A lock is obtained by the following mechanisms:
LockMode.WRITE
is acquired automatically when Hibernate updates or inserts
a row.
LockMode.UPGRADE
may be acquired upon explicit user request using
SELECT ... FOR UPDATE
on databases which support that syntax.
LockMode.UPGRADE_NOWAIT
may be acquired upon explicit user request using a
SELECT ... FOR UPDATE NOWAIT
under Oracle.
LockMode.READ
is acquired automatically when Hibernate reads data
under Repeatable Read or Serializable isolation level. May be re-acquired by explicit user
request.
LockMode.NONE
represents the absence of a lock. All objects switch to this
lock mode at the end of a Transaction
. Objects associated with the session
via a call to update()
or saveOrUpdate()
also start out
in this lock mode.
The "explicit user request" is expressed in one of the following ways:
A call to Session.load()
, specifying a LockMode
.
A call to Session.lock()
.
A call to Query.setLockMode()
.
If Session.load()
is called with UPGRADE
or
UPGRADE_NOWAIT
, and the requested object was not yet loaded by
the session, the object is loaded using SELECT ... FOR UPDATE
.
If load()
is called for an object that is already loaded with
a less restrictive lock than the one requested, Hibernate calls
lock()
for that object.
Session.lock()
performs a version number check if the specified lock
mode is READ
, UPGRADE
or
UPGRADE_NOWAIT
. (In the case of UPGRADE
or
UPGRADE_NOWAIT
, SELECT ... FOR UPDATE
is used.)
If the database does not support the requested lock mode, Hibernate will use an appropriate alternate mode (instead of throwing an exception). This ensures that applications will be portable.