Which APIs let you remove entries from Hibernate's second-level cache programmatically, and what is the operational risk of the broadest of them?

## The portable API JPA standardises a small cache-control surface reached from the factory: ``` Cache cache = em.getEntityManagerFactory().getCache(); cache.evict(Product.class, 42L); // one entry cache.evict(Product.class); // every Product cache.evictAll(); // the whole second-level cache cache.contains(Product.class, 42L); ``` `contains` is useful in tests and diagnostics: it tells you whether the shared cache currently holds that identifier, which is the honest way to prove caching is actually happening rather than assuming it from a configuration file. ## The Hibernate API Unwrapping to Hibernate gives finer control, because Hibernate stores several distinct kinds of data: ``` CacheImplementor cache = sessionFactory.getCache(); cache.evictEntityData(Product.class, 42L); cache.evictEntityData(Product.class); cache.evictCollectionData(Order.class.getName() + ".lines"); cache.evictNaturalIdData(Product.class); cache.evictQueryRegion("reports"); cache.evictDefaultQueryRegion(); ``` The separation matters: evicting entity data does not evict cached collections that reference it, and cached query results live in their own regions with their own validity rules. A partial eviction that forgets one of these leaves an inconsistent picture, for example a cached collection of identifiers whose entities are gone. ## When you legitimately reach for these - After a job that wrote to the schema outside Hibernate (a loader, an external service, a DBA fix), evict the entity type or the affected keys. - After a native SQL statement whose tables you did not declare as synchronized. - During tests, to prove a read really goes to the database. - On a controlled configuration or reference-data change: evict the region rather than restarting the process. ## Why evictAll is dangerous A full eviction removes the buffer between your application and the database in one step. Every request that was being served from memory now issues SQL, all at the same moment, from every thread. Where the cached entities were hiding an N+1 access pattern, that pattern becomes visible as a flood. Two aggravating factors: in a cluster, an administrative endpoint that evicts all nodes multiplies the burst, and if the eviction happens under load, the refill itself competes with normal traffic and can push latency past timeouts, causing retries that add still more load. Mitigations if you must offer such an operation: expose it only to operators, do it per region, do it during a quiet period, and consider a warm-up read path afterwards. ## Eviction is local unless the provider says otherwise A plain eviction call affects the cache of the JVM that ran it. Whether other nodes hear about it depends entirely on the provider's topology. With a clustered, invalidation-aware provider the removal is broadcast; with independent per-node caches it is not, and "I evicted it" only means "I evicted it here". Any operational procedure built on manual eviction must state which of those it is. ## What interviewers listen for Name the portable API, know that Hibernate has a richer one with separate entity/collection/natural-id/query calls, and show judgement about granularity and cluster scope rather than reaching for `evictAll()` as the answer to every staleness problem.