You are deciding the Hibernate second-level cache concurrency strategy for each entity in a system: some are immutable reference tables, some change a few times a day, some are written constantly. How do you make that call per entity, and when do you decide not to cache an entity at all?

## The two axes Every sensible choice here falls out of two properties of the entity, not of the framework: 1. **Mutation rate** — how often rows change, through normal application traffic (not deployments). 2. **Staleness sensitivity** — what actually goes wrong if a user or another service reads a value that is a few seconds behind. A third, quieter factor decides whether to cache at all: **reuse**. A cache only pays if the same keys are read many times between writes. ## Mapping entities to strategies **Immutable reference data → READ_ONLY.** Currencies, countries, ISO codes, tax jurisdictions that only change with a release, immutable audit or event rows. No locking, no version bookkeeping, no invalidation messages in a cluster. When such data does change with a deployment, treat it as replacement: migrate, then evict the region or roll the nodes. This is the highest-value caching in most systems — small tables joined or looked up constantly. **Rarely mutated, staleness-tolerant → NONSTRICT_READ_WRITE.** Feature flags, pricing tables refreshed nightly, editorial content, configuration edited by an admin now and then. You accept that a concurrent reader can repopulate a pre-commit value and that the entry may be briefly stale, so pair it with a bounded time-to-live. The question to ask the business is concrete: *if someone sees the old value for ten seconds, what breaks?* If the answer is "nothing", take the cheaper strategy. **Mutable, read-mostly, staleness-visible → READ_WRITE.** Customer profiles, account records, order headers — read on many requests, written occasionally, and where showing a value a user just changed would be a visible bug. Give these entities a `@Version` column: READ_WRITE uses the version to decide whether the post-commit state may replace the soft lock, which is more precise than the timestamp fallback. Accept the extra per-write cache round-trips. **Atomicity required and JTA already present → TRANSACTIONAL.** Rare in practice. It only exists if you run a JTA transaction manager and a provider that can enlist in the transaction, and it adds two-phase-commit cost to every write. Choosing it drags an architectural commitment across the whole system, so it should be a deliberate platform decision, not a per-entity afterthought. ## When not to cache This is the answer that separates a senior from a principal response. Reasons to leave an entity out of the second-level cache entirely: - **Write rate approaches read rate.** Under READ_WRITE, every write costs a lock put plus a state put or a removal, and readers racing the write miss anyway. You pay full price for a low hit rate. - **Hot keys under concurrent writers.** Repeated concurrent soft locks on the same key mean post-commit replacement keeps being refused, so the entry stays empty and every read hits the database — the cache does nothing but add work. - **Poor reuse.** Entities read once per key (event rows, per-request records) evict each other and give near-zero hit rate while consuming memory. - **Large state or wide graphs.** Memory pressure and serialization cost in a distributed provider can outweigh the saved query. - **Strict freshness requirements.** If the domain says a value must never be stale — a balance used to authorise a payment — the right control is a database read (with the appropriate locking at that layer), not a cache tuned to be nearly fresh. In a clustered deployment, add the operational cost: every write on a cached mutable entity generates invalidation traffic to every node. A modestly cached, heavily written entity can make a cluster slower than no cache at all. ## How to decide rather than guess Start from the data, not the annotations. Rank entities by read volume and by write volume (query logs, statistics, application metrics). Cache the top-read, low-write entities first; leave the rest alone. Then verify: watch hit ratio, miss ratio, eviction and put counts per region. A region with a low hit ratio or eviction count close to put count is a region that should be shrunk, retuned, or removed. Do the same after each change in traffic shape — a strategy chosen for last year's read/write mix is not automatically right for this year's. Finally, keep the choice explicit per entity in the mapping rather than relying on a global default: a reader of the code should be able to see the consistency contract for that entity without knowing the container's configuration.