Second-level and query caches
On This Lesson 4 topics
This lesson is planned. The outline below lists the topics it will cover. The full lesson has not been published yet.
In this lesson
decide whether a cache is worth it.
Planned topics
- First-level cache: the persistence context, per transaction; always on.
- Second-level cache: shared across sessions through a provider (Ehcache, Infinispan, Caffeine via JCache); needs
@Cacheper entity. - Good candidates: read-mostly reference data (countries, categories). Bad: frequently changed or large mutable entities.
- Query cache stores result ids and is invalidated on any write to the tables involved; rarely a win.
- Multi-instance deployments need a distributed or invalidating provider; often a dedicated cache (Redis, later modules) is simpler.
- A cache hides bugs and adds staleness; measure hit ratio before keeping it.
Draft outline details
Demonstration
a decision table: entity, read/write ratio, staleness allowed, cache yes/no.
Check your understanding
Which entity suits a second-level cache: product stock or country list?
Show answer
Country list; stock changes constantly.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.