some more documentation about lock modes
Signed-off-by: Gavin King <gavin@hibernate.org>
This commit is contained in:
parent
8c3b68cd78
commit
43a8851d51
|
@ -943,8 +943,20 @@ an entity is written to the database using
|
|||
| `PESSIMISTIC_WRITE` | A pessimistic `for update` lock
|
||||
| `PESSIMISTIC_FORCE_INCREMENT` | A pessimistic lock enforced using an immediate
|
||||
`update` to increment the version
|
||||
| `NONE` | No lock; assigned when an entity is read from the second-level cache
|
||||
|===
|
||||
|
||||
Note that an `OPTIMISTIC` lock is always verified at the end of the transaction, even when the entity has not been modified.
|
||||
This is slightly different to what most people mean when they talk about an "optimistic lock".
|
||||
It's never necessary to request an `OPTIMISTIC` lock on a modified entity, since the version number is always verified when a SQL `update` is executed.
|
||||
|
||||
[CAUTION]
|
||||
====
|
||||
JPA has its own `LockModeType`, which enumerates most of the same modes.
|
||||
However, JPA's `LockModeType.READ` is a synonym for `OPTIMISTIC` -- it's not the same as Hibernate's `LockMode.READ`.
|
||||
Similarly, `LockModeType.WRITE` is a synonym for `OPTIMISTIC_FORCE_INCREMENT` and is not the same as `LockMode.WRITE`.
|
||||
====
|
||||
|
||||
[[statistics]]
|
||||
=== Collecting statistics
|
||||
|
||||
|
|
Loading…
Reference in New Issue