diff --git a/documentation/src/main/asciidoc/introduction/Tuning.adoc b/documentation/src/main/asciidoc/introduction/Tuning.adoc
index daff6e6569..73de3e8585 100644
--- a/documentation/src/main/asciidoc/introduction/Tuning.adoc
+++ b/documentation/src/main/asciidoc/introduction/Tuning.adoc
@@ -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