Hibernate implements no cache itself — it delegates to a provider through a RegionFactory. Explain how that plug-in point works, and how you would choose between EhCache, Infinispan and Caffeine behind the JCache (JSR-107) bridge.

## The SPI Hibernate's caching is deliberately pluggable. The core contract is `org.hibernate.cache.spi.RegionFactory`, which Hibernate uses to build **regions** — named key/value stores — of a few kinds: entity regions (`DomainDataRegion` in modern versions), collection regions, natural-id regions, the query-results region, and the update-timestamps region. On top of raw storage, the factory supplies **access strategies** implementing the semantics of `READ_ONLY`, `READ_WRITE`, `NONSTRICT_READ_WRITE` and `TRANSACTIONAL`, including the soft-lock protocol that read-write uses to keep a concurrent write from publishing stale state. Hibernate never stores objects there. It stores dehydrated state arrays keyed by a cache key built from the entity id, the entity's role, and (where relevant) the tenant identifier. That is why the provider only needs to be a competent map with eviction — all ORM semantics live on Hibernate's side of the SPI. ## The JCache bridge Rather than maintain an adapter per cache product, Hibernate ships `hibernate-jcache`, which implements `RegionFactory` over **JSR-107**. Configuration is small: ``` hibernate.cache.region.factory_class=jcache hibernate.javax.cache.provider=<CachingProvider FQCN> # needed only if several are on the classpath hibernate.javax.cache.uri=classpath:cache-config.xml # the provider's own config file hibernate.javax.cache.missing_cache_strategy=fail ``` Hibernate resolves a `CachingProvider`, obtains a `CacheManager` from the URI, and calls `getCache(regionName)` per region. Region sizing, expiry and tiering are therefore expressed in the **provider's** configuration language, not in Hibernate properties — a frequent surprise for people expecting `hibernate.cache.*.ttl` knobs. The `missing_cache_strategy` default of `fail` matters: if the provider config has no cache for `com.acme.Product`, startup breaks rather than quietly creating an unbounded region. `create-warn` is a reasonable transitional setting; `create` in production invites unbounded growth. ## Choosing a provider **Caffeine** is a modern in-JVM cache with a near-optimal admission/eviction policy (W-TinyLFU) and very low overhead. Its `caffeine-jcache` module makes it a JSR-107 provider. Choose it for single-node deployments, or multi-node deployments where per-node copies of reference data are acceptable. **EhCache 3** is also local but offers declarative, well-documented tiering — heap, offheap (serialized, outside the GC's reach), and disk — with per-region sizing in units of entries or bytes. Choose it when regions are large enough that keeping them on heap hurts GC, or when operators want XML-level control. **Infinispan** is a distributed data grid. Beyond JCache it ships a Hibernate-specific region factory that understands entity and query regions and does **cluster-wide invalidation**: when a node writes, peers drop their copies. Choose it when correctness across nodes matters more than the last microsecond — and accept that you have added a distributed system to operate, with its own failure modes. ## The real decision axis Raw benchmarks rarely decide this. The questions that do: 1. **How many nodes, and can they diverge?** A local cache on N nodes means N independent staleness windows, each bounded only by TTL. If the domain tolerates that (currency lists, feature catalogues), local is fine and far simpler. If not, you need cluster-aware invalidation — or you should not cache that entity. 2. **Who else writes the data?** A batch job, another service, or Hibernate bulk HQL `update`/`delete` can bypass the cache entirely. No provider fixes that; it is a modelling decision. 3. **Heap versus process memory.** Offheap or a grid keeps large datasets out of the GC's working set at the price of serialization cost per access. 4. **Operability.** Every provider adds config files, metrics and a failure mode. A distributed cache adds split-brain and rebalancing questions your on-call rota now owns. ## Verification Whichever provider you choose, wire `hibernate.generate_statistics=true` and export per-region hit/miss/put counts alongside the provider's own metrics. Two numbers matter: hit ratio per region (is this region earning its heap?) and eviction rate (is it too small to ever warm up?).