diff --git a/documentation/src/main/asciidoc/introduction/Advanced.adoc b/documentation/src/main/asciidoc/introduction/Advanced.adoc
index 5bf1303cc3..a341b4f469 100644
--- a/documentation/src/main/asciidoc/introduction/Advanced.adoc
+++ b/documentation/src/main/asciidoc/introduction/Advanced.adoc
@@ -507,7 +507,6 @@ Hibernate Spatial lets us work with spatial types just as we would with any of t
 [source,java]
 ----
 var geometryFactory = new GeometryFactory();
-
 ...
 
 Point point = geometryFactory.createPoint(new Coordinate(10, 5));
@@ -761,6 +760,8 @@ When the session flushes, the snapshot state is compared to the current state of
 Maintaining these snapshots does have an impact on performance.
 - _With_ bytecode enhancement, we may avoid this cost by intercepting writes to the field and recording these modifications as they happen.
 
+This optimization isn't _completely_ transparent, however.
+
 [CAUTION]
 ====
 Interception-based change detection is less accurate than snapshot-based dirty checking.
diff --git a/documentation/src/main/asciidoc/introduction/Tuning.adoc b/documentation/src/main/asciidoc/introduction/Tuning.adoc
index 04653ef2ac..2084065686 100644
--- a/documentation/src/main/asciidoc/introduction/Tuning.adoc
+++ b/documentation/src/main/asciidoc/introduction/Tuning.adoc
@@ -321,6 +321,15 @@ Much better!
 
 You can find much more information about association fetching in the {association-fetching}[User Guide].
 
+Of course, an alternative way to avoid many round trips to the database is to cache the data we need in the Java client.
+If we're expecting to find the data in a local cache, we probably don't need join fetching at all.
+
+[TIP]
+====
+What if we can't be _certain_ all the data will be in the cache?
+In that case, we might want to enable batch fetching, just to reduce the cost when some data is missing.
+====
+
 [[second-level-cache]]
 === The second-level cache
 
@@ -428,6 +437,7 @@ This strategy uses "soft" locks to prevent concurrent transactions from retrievi
 
 Which policies make sense may also depend on the underlying second-level cache implementation.
 
+[%unbreakable]
 [NOTE]
 // .The JPA-defined `@Cacheable` annotation
 ====
@@ -595,6 +605,7 @@ Finally, there's a way to globally disable the second-level cache:
 
 When `hibernate.cache.region.factory_class` is set, this property defaults to `true`.
 
+[%unbreakable]
 [TIP]
 ====
 This setting lets us easily disable the second-level cache completely when troubleshooting or profiling performance.
@@ -747,6 +758,7 @@ A Hibernate `CacheMode` packages a `CacheRetrieveMode` with a `CacheStoreMode`.
 There's no particular reason to prefer Hibernate's `CacheMode` over the JPA equivalents.
 This enumeration only exists because Hibernate had cache modes long before they were added to JPA.
 
+[%unbreakable]
 [TIP]
 ====
 For "reference" data, that is, for data which is expected to always be found in the second-level cache, it's a good idea to _prime_ the cache at startup.