The JPA property jakarta.persistence.sharedCache.mode accepts ENABLE_SELECTIVE, DISABLE_SELECTIVE, ALL and NONE. Explain what each value means for which entities get cached, and which one you would run in production.

## The property's job The second-level cache has two independent gates. One is the infrastructure gate: `hibernate.cache.use_second_level_cache` plus a working `RegionFactory`. The other is the **policy gate**: given that caching is available, which entity types actually participate? That second gate is `jakarta.persistence.sharedCache.mode`, a standard JPA property (spelled `javax.persistence.sharedCache.mode` before the Jakarta rename) that can also be written as `<shared-cache-mode>` in `persistence.xml`. ## The five values **ENABLE_SELECTIVE** — opt-in. An entity is cached only if it carries `@Cacheable` (whose `value` defaults to `true`). Anything unannotated is untouched. This is what almost every real system runs, and it is what Hibernate does when the property is absent. **DISABLE_SELECTIVE** — opt-out. Every entity is cached unless it carries `@Cacheable(false)`. The blast radius is the whole domain model, so a new entity is cached the moment it is written. **ALL** — caches every entity and ignores `@Cacheable` entirely, including `@Cacheable(false)`. Legitimate for a schema that is genuinely reference data (currencies, country codes, tax bands) or for a quick before/after measurement. **NONE** — disables participation for every entity even though the infrastructure is present. Distinct from turning off `use_second_level_cache`: the regions and factory still exist, so you can flip the switch by configuration alone, per environment, without redeploying. That makes it a valuable incident lever and a good test setting. **UNSPECIFIED** — the formal default when nothing is set; the provider decides, and Hibernate treats it as ENABLE_SELECTIVE. ## Why opt-in wins Caching an entity is not free and is not universally correct. *Cost.* Each write to a cached entity must also touch the region — invalidate, or write the new state under a lock, depending on the concurrency strategy. For a table with a high write:read ratio, you pay that on every write and rarely get a hit back. Under an opt-out mode, your busiest write-heavy tables are enrolled by default — exactly backwards. *Memory.* Every cached type consumes a region with its own sizing. Blanket caching an entity with large `@Lob` fields or wide rows can push heap pressure and GC pauses well past whatever query time you saved. *Correctness.* Cached state is only as fresh as your invalidation. If some rows are also written by a batch job, a stored procedure, another service, or Hibernate bulk `UPDATE`/`DELETE` statements, the cache can serve stale values. Deciding that per entity is a conscious act; inheriting it from a global mode is not. *Reviewability.* Under ENABLE_SELECTIVE, `@Cacheable` in a diff is a visible, discussable decision. Under DISABLE_SELECTIVE or ALL, a new entity class joins the cache with no diff at all. ## Interaction with @Cache The mode governs *whether* an entity is cached; Hibernate's `@Cache` governs *how* — concurrency strategy and region. Under ALL, entities without `@Cache` get the strategy from `hibernate.cache.default_cache_concurrency_strategy`, so a blanket mode also blanket-applies a strategy nobody chose per entity. That is another reason to keep the enrolment explicit. ## Practical usage A workable pattern is ENABLE_SELECTIVE everywhere, with NONE in the test profile so tests never depend on cache residency and never leak state between cases. When investigating suspected stale reads in production, switching the mode to NONE is a fast, low-risk bisection: if the anomaly disappears, the cache is implicated; if not, look elsewhere. Keep in mind that `@Cacheable` is not inherited in a useful way across every mapping strategy — for inheritance hierarchies, annotate the root entity, since the cache region is organised by the root type.