Hibernate lets you choose a second-level cache concurrency strategy per entity: READ_ONLY, NONSTRICT_READ_WRITE, READ_WRITE, or TRANSACTIONAL. What consistency does each guarantee, and what kind of data is each meant for?

## Why a strategy exists at all The second-level cache is shared by every persistence context in the process, and with a clustered provider potentially across nodes. That makes it shared mutable state living *outside* the database, and the database is the only component that actually enforces transactions on your data. So when a transaction changes a row, something has to decide what happens to the cached copy: replace it, throw it away, block readers, or coordinate with the transaction. Hibernate does not guess. You declare a **cache concurrency strategy** per entity (and per collection), and that declaration is the contract about how much staleness you are willing to accept in exchange for how much coordination cost. The strategy is declared with Hibernate's `@Cache(usage = ...)` annotation. The JPA-standard `@Cacheable` annotation only says *whether* to cache, not how, so when only `@Cacheable` is present Hibernate falls back to the `hibernate.cache.default_cache_concurrency_strategy` setting or the region factory's own default. ## READ_ONLY Use it for data that is inserted and then never updated: currency codes, country lists, immutable audit rows, product catalogue entries that are versioned by insert rather than edited. Because nothing ever changes, there is no consistency problem to solve. Hibernate does no locking, keeps no version metadata for reconciliation, and may hand out the cached state directly. If application code does modify such an entity, Hibernate refuses at flush time with an exception rather than silently caching a lie. Deletes are handled by simply dropping the entry. This is the fastest and the only strategy that is *unconditionally* correct. ## NONSTRICT_READ_WRITE This is the "cheap and slightly wrong" option for data that is technically mutable but almost never mutated. There is no locking whatsoever. When a transaction updates the entity, Hibernate does not put the new state into the cache; it **removes** the entry — at flush time and again after the transaction completes — so the next reader reloads from the database and repopulates. The gap between the database commit and the cache removal, plus the possibility that a concurrent reader loads the pre-commit row and writes it into the cache after the removal, means another session can read a stale value for a short window. Hibernate documents this openly: the strategy makes no guarantee that the cached item is the latest version. Combine it with a modest time-to-live so any stale entry cannot survive long. ## READ_WRITE This is the strategy for genuinely mutable, read-mostly entities where you cannot tolerate obviously stale reads. It gets close to read-committed consistency on a cache that has no transactions of its own by using a **soft lock**: before the write, the cached entry is replaced by a lock marker; while that marker is present, readers treat the region as a miss and go to the database, and competing writers cannot install a value. After the transaction completes, the lock is replaced by the new state (on commit) or simply released so the next read reloads (on rollback, or when several writers contended). Locks carry an expiry so a crashed process cannot poison a region forever. The cost is extra puts, extra cache round-trips, and cache misses for readers during writes — which is exactly why it is a poor fit for hot, frequently written rows. ## TRANSACTIONAL Here the cache itself is transactional and is enlisted as a resource in the same JTA transaction as the database, typically via two-phase commit. Cache and database therefore reach the same decision: commit both or roll back both, with no window in which one has the change and the other does not. It also means changes made in your transaction are visible to *your* subsequent reads through the cache, consistently. The price is a JTA transaction manager, a provider that supports transactional access, and 2PC overhead on every write. Most applications running on a local resource-local transaction setup cannot use it at all. ## How they line up Ordered by increasing strength and cost: READ_ONLY (no writes possible), NONSTRICT_READ_WRITE (eventual, brief staleness), READ_WRITE (roughly read-committed, no dirty reads from cache), TRANSACTIONAL (atomic with the database). Note that none of them gives you repeatable-read or serializable semantics across transactions — the second-level cache is an optimisation layered on top of whatever the database enforces, not a replacement for it. The right answer in an interview is not "always READ_WRITE"; it is that the strategy follows the entity's mutability and write rate.