nice tip and segue into caching
This commit is contained in:
parent
16fd099118
commit
f2591759f3
|
@ -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.
|
||||||
|
|
|
@ -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.
|
||||||
|
|
Loading…
Reference in New Issue