From 8878a19161d2454676972620bbd5ef14df98f0bf Mon Sep 17 00:00:00 2001 From: "nathan.xu" Date: Sat, 29 Jun 2024 15:37:57 -0400 Subject: [PATCH] HHH-18320 fix some synatx errors in Locking user guide chapter --- .../userguide/chapters/locking/Locking.adoc | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/documentation/src/main/asciidoc/userguide/chapters/locking/Locking.adoc b/documentation/src/main/asciidoc/userguide/chapters/locking/Locking.adoc index 75c8acd82f..e1a0aa2fc7 100644 --- a/documentation/src/main/asciidoc/userguide/chapters/locking/Locking.adoc +++ b/documentation/src/main/asciidoc/userguide/chapters/locking/Locking.adoc @@ -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`. |=======================================================================