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

add some javadoc links from Tuning chapter 

Signed-off-by: Gavin King <gavin@hibernate.org>
This commit is contained in:
Gavin King 2024-05-14 14:31:08 +02:00
parent 43a8851d51
commit 327399e801
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
documentation/src/main/asciidoc/introduction/Tuning.adoc
View File

@ -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