Hibernate
/
hibernate-orm
mirror of https://github.com/hibernate/hibernate-orm
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

HHH-18320 fix some synatx errors in Locking user guide chapter

This commit is contained in:
nathan.xu 2024-06-29 15:37:57 -04:00 committed by Sanne Grinovero
parent c1624dce98
commit 8878a19161
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
documentation/src/main/asciidoc/userguide/chapters/locking/Locking.adoc
View File

@ -5,7 +5,7 @@
:example-dir-locking: {core-project-dir}/src/test/java/org/hibernate/orm/test/locking
:extrasdir: extras
In a relational database, locking refers to actions taken to prevent data from changing between the time it is read and the time is used.
In a relational database, locking refers to actions taken to prevent data from changing between the time it is read and the time it is used.
Your locking strategy can be either optimistic or pessimistic.
@ -92,7 +92,7 @@ The version column can be any kind of type, as long as you define and implement
Your application is forbidden from altering the version number set by Hibernate.
To artificially increase the version number, see the documentation for properties `LockModeType.OPTIMISTIC_FORCE_INCREMENT` or
`LockModeType.PESSIMISTIC_FORCE_INCREMENT` check in the Hibernate Entity Manager reference documentation.
`LockModeType.PESSIMISTIC_FORCE_INCREMENT` in the Hibernate Entity Manager reference documentation.
[NOTE]
====
@ -103,7 +103,7 @@ If the version number is generated by the database, such as a trigger, use the a
===== Timestamp
Timestamps are a less reliable way of optimistic locking than version numbers but can be used by applications for other purposes as well.
Timestamping is automatically used if you the `@Version` annotation on a `Date` or `Calendar` property type.
Timestamping is automatically used if you specify the `@Version` annotation on a `Date` or `Calendar` property type.
[[locking-optimistic-version-timestamp-example]]
.Using timestamps for optimistic locking
@ -190,7 +190,7 @@ For this reason, you should only use this feature if you can accommodate lost up
===== Versionless optimistic locking
Although the default `@Version` property optimistic locking mechanism is sufficient in many situations,
sometimes, you need rely on the actual database row column values to prevent *lost updates*.
sometimes, you need to rely on the actual database row column values to prevent *lost updates*.
Hibernate supports a form of optimistic locking that does not require a dedicated "version attribute".
This is also useful for use with modeling legacy schemas.
@ -302,7 +302,7 @@ If you do need to obtain exclusive pessimistic locks or re-obtain locks at the s
[NOTE]
====
Hibernate always uses the locking mechanism of the database, and never lock objects in memory.
Hibernate always uses the locking mechanism of the database, and never locks objects in memory.
====
[[locking-LockMode]]
@ -315,13 +315,13 @@ Jakarta Persistence comes with its own {jpaJavadocUrlPrefix}LockModeType.html[`L
|=======================================================================
|`LockModeType`|`LockMode`|Description
|`NONE`|`NONE` |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.
|`NONE`|`NONE` |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.
|`READ` and `OPTIMISTIC`|`READ` | The entity version is checked towards the end of the currently running transaction.
|`WRITE` and `OPTIMISTIC_FORCE_INCREMENT`|`WRITE` | The entity version is incremented automatically even if the entity has not changed.
|`PESSIMISTIC_FORCE_INCREMENT`|`PESSIMISTIC_FORCE_INCREMENT` | The entity is locked pessimistically and its version is incremented automatically even if the entity has not changed.
|`PESSIMISTIC_READ`|`PESSIMISTIC_READ` | The entity is locked pessimistically using a shared lock if the database supports such a feature. Otherwise, an explicit lock is used.
|`PESSIMISTIC_WRITE`|`PESSIMISTIC_WRITE`, `UPGRADE` | The entity is locked using an explicit lock.
|`PESSIMISTIC_WRITE` with a `jakarta.persistence.lock.timeout` setting of 0 |`UPGRADE_NOWAIT` | The lock acquisition request fails fast if the row s already locked.
|`PESSIMISTIC_WRITE` with a `jakarta.persistence.lock.timeout` setting of 0 |`UPGRADE_NOWAIT` | The lock acquisition request fails fast if the row is already locked.
|`PESSIMISTIC_WRITE` with a `jakarta.persistence.lock.timeout` setting of -2 |`UPGRADE_SKIPLOCKED` | The lock acquisition request skips the already locked rows. It uses a `SELECT ... FOR UPDATE SKIP LOCKED` in Oracle and PostgreSQL 9.5, or `SELECT ... with (rowlock, updlock, readpast) in SQL Server`.
|=======================================================================