Hibernate second-level cache and external backup utility restoration boundary

Direct Answer

Yes. If the restored data overlaps entities that were cached in Hibernate's second-level cache, you must explicitly evict or invalidate those cache regions before new sessions read them. The L2 cache does not detect external database changes, so pre-restore entries can be served as stale data indefinitely.

Confirmed facts versus setup-dependent behavior

Confirmed: A restore performed by an external utility bypasses Hibernate's transaction and event system. The SessionFactory cache has no built-in hook to observe those changes, and no Hibernate 5.x or 6.x release adds automatic invalidation for out-of-band writes.

Setup-dependent: Whether stale reads actually occur depends on whether the affected entity regions were populated in L2 before the restore and whether your cache provider persists entries across application restarts. If the restore also overwrites cache region files, provider-specific behavior applies.

Steps for this case

1. After the restore completes and before serving traffic, evict the affected entity regions through the SessionFactory cache API.
2. If you cannot identify every affected region, clear the entire L2 cache.
3. If the cache lives in an external process (for example, a distributed Redis or Hazelcast grid), issue the eviction through that provider's administrative interface or restart the application so it reconnects to a fresh region.

Pagination does not validate cache coherence

Deterministic pagination with setFirstResult and maxResults returns correct row counts from the database after the restore. It does not purge or refresh L2 entries. A paginated query can show the right number of rows while individual entity lookups still return stale cached objects.

Backup serialization boundary

Exclude L2 cache snapshots from external backup serialization. Hibernate 5.x and 6.x do not guarantee binary compatibility of internal cache formats across major releases. Restoring serialized cache data from a different major version can cause deserialization failures or silent corruption.

Verification

After the restore, start a new SessionFactory, query an entity that was previously cached, and compare the returned state against the restored database row. If the object is stale without explicit eviction, the cache must be cleared before production use.

// Scoped eviction after external restore
sessionFactory.getCache().evict(com.example.model.Entity.class);

Diagnostic question: Does the external backup utility include serialized Hibernate L2 cache files, or only database dump data? If it includes cache files, excluding them from the backup set is part of the fix; if it does not, region eviction alone is sufficient.