From 327399e801ea67c3fe174532e30b296ff7722fec Mon Sep 17 00:00:00 2001 From: Gavin King Date: Tue, 14 May 2024 14:31:08 +0200 Subject: [PATCH] add some javadoc links from Tuning chapter Signed-off-by: Gavin King --- .../src/main/asciidoc/introduction/Tuning.adoc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/documentation/src/main/asciidoc/introduction/Tuning.adoc b/documentation/src/main/asciidoc/introduction/Tuning.adoc index 73de3e8585..eb2b375995 100644 --- a/documentation/src/main/asciidoc/introduction/Tuning.adoc +++ b/documentation/src/main/asciidoc/introduction/Tuning.adoc @@ -239,7 +239,7 @@ session.setSubselectFetchingEnabled(true); [%unbreakable] [TIP] ==== -We may request subselect fetching more selectively by annotating a collection or many-valued association with the `@Fetch` annotation. +We may request subselect fetching more selectively by annotating a collection or many-valued association with the link:{doc-javadoc-url}/org/hibernate/annotations/Fetch.html[`@Fetch`] annotation. [source,java] ---- @ManyToMany @Fetch(SUBSELECT) @@ -362,7 +362,7 @@ So a second-level cache is often by far the easiest way to improve the performan And so the cache is a potential source of bugs which are difficult to isolate and reproduce. Therefore, by default, an entity is not eligible for storage in the second-level cache. -We must explicitly mark each entity that will be stored in the second-level cache with the `@Cache` annotation from `org.hibernate.annotations`. +We must explicitly mark each entity that will be stored in the second-level cache with the link:{doc-javadoc-url}/org/hibernate/annotations/Cache.html[`@Cache`] annotation from `org.hibernate.annotations`. But that's still not enough. Hibernate does not itself contain an implementation of a second-level cache, so it's necessary to configure an external _cache provider_. @@ -529,7 +529,7 @@ There's no need for this association to be lazily fetched, since we're expecting But on the other hand, if we leave it marked for eager fetching then, by default, Hibernate will often fetch it using a join. This places completely unnecessary load on the database. -The solution is the `@Fetch` annotation: +The solution is the link:{doc-javadoc-url}/org/hibernate/annotations/Fetch.html[`@Fetch`] annotation: [source,java] ---- @@ -694,7 +694,7 @@ As is generally the case with any second-level cache, the query cache can break For the most part, the second-level cache is transparent. Program logic which interacts with the Hibernate session is unaware of the cache, and is not impacted by changes to caching policies. -At worst, interaction with the cache may be controlled by specifying of an explicit `CacheMode`: +At worst, interaction with the cache may be controlled by specifying of an explicit link:{doc-javadoc-url}/org/hibernate/CacheMode.html[`CacheMode`]: [source,java] ---- @@ -918,7 +918,7 @@ Indeed, the usual practice is to avoid having transactions that span user intera That said, there _is_ also a place for pessimistic locks, which can sometimes reduce the probability of transaction rollbacks. Therefore, the `find()`, `lock()`, and `refresh()` methods of the reactive session accept an optional `LockMode`. -We can also specify a `LockMode` for a query. +We can also specify a link:{doc-javadoc-url}/org/hibernate/LockMode.html[`LockMode`] for a query. The lock mode can be used to request a pessimistic lock, or to customize the behavior of optimistic locking: .Optimistic and pessimistic lock modes