Java Reference
In-Depth Information
to Restaurant use case to illustrate how to use them. The Hibernate version of this
business logic is similar to the
JDO
version you saw in section 12.3.2. The only dif-
ference is that the
OrderRepository
uses Hibernate instead of
JDO
.
Using optimistic locking
Hibernate supports optimistic locking using a version or a timestamp column or
by comparing columns. The version or timestamp column and the corresponding
property are specified by using a
<version>
or
<timestamp>
element in a class's
ORM
document. For example, the following excerpt from the
Order
class's map-
ping document configures the class to use a version column:
<hibernate-mapping>
<class
name="net.chrisrichardson.foodToGo.domain.Order"
table="PLACED_ORDER">
<id name="id" column="ORDER_ID" unsaved-value="-1">
<generator class="native"/>
</id>
<version name="version" column="VERSION"/>
…
</class>
This mapping document specifies that the
Order
class map to the
PLACED_ORDER
table and use the
VERSION
column for optimistic locking. A class is configured to
use a timestamp in a similar way.
An application can use the
optimistic-lock
attribute of the
<class>
element to
specify that Hibernate should implement the optimistic locking check by compar-
ing columns. Hibernate can either check all columns or just the changed columns.
Here is an example of how to configure Hibernate to check changed columns:
<class
name="net.chrisrichardson.foodToGo.domain.Order"
dynamic-update=
"
true
"
optimistic-lock=
"
dirty
"
table="PLACED_ORDER">
…
</class>
In order for Hibernate to compare columns, the application must also specify
dynamic-update="true"
, which tells Hibernate to generate
SQL
UPDATE
statements
that update only changed columns.
Hibernate performs the optimistic locking check when it updates the database
to reflect the changes made to the objects, which happens when the application
executes a Hibernate query or calls
Session.flush()
, which updates the database
Search WWH ::
Custom Search