nice tip and segue into caching

This commit is contained in:
Gavin 2023-06-11 14:47:12 +02:00 committed by Christian Beikov
parent 16fd099118
commit f2591759f3
2 changed files with 14 additions and 1 deletions

View File

@ -507,7 +507,6 @@ Hibernate Spatial lets us work with spatial types just as we would with any of t
[source,java] [source,java]
---- ----
var geometryFactory = new GeometryFactory(); var geometryFactory = new GeometryFactory();
... ...
Point point = geometryFactory.createPoint(new Coordinate(10, 5)); 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. 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. - _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] [CAUTION]
==== ====
Interception-based change detection is less accurate than snapshot-based dirty checking. Interception-based change detection is less accurate than snapshot-based dirty checking.

View File

@ -321,6 +321,15 @@ Much better!
You can find much more information about association fetching in the {association-fetching}[User Guide]. 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]] [[second-level-cache]]
=== The 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. Which policies make sense may also depend on the underlying second-level cache implementation.
[%unbreakable]
[NOTE] [NOTE]
// .The JPA-defined `@Cacheable` annotation // .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`. When `hibernate.cache.region.factory_class` is set, this property defaults to `true`.
[%unbreakable]
[TIP] [TIP]
==== ====
This setting lets us easily disable the second-level cache completely when troubleshooting or profiling performance. 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. 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. This enumeration only exists because Hibernate had cache modes long before they were added to JPA.
[%unbreakable]
[TIP] [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. 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.