Stale Entity State during Paginated Query Retrieval in Hibernate L2C

Short Answer

Hibernate has no built-in mechanism to selectively refresh L2C entities that a paginated query happens to return. The practical options are CacheMode.IGNORE (or REFRESH) on that query, explicit eviction of the affected entities or region, or session.refresh() per entity. And the Query Cache question has a cleaner answer than you might expect: it never held your entity state in the first place.

Separating the Two Caches

The confusion usually comes from treating "the cache" as one thing. There are two distinct mechanisms:

• Second-Level Cache (L2C): stores dehydrated entity state, keyed by entity ID. This is where staleness lives.
• Query Cache: stores only the query string, parameter bindings, and the list of entity IDs that matched. It stores no entity state at all.

So when your paginated query runs, the ID list may come from the database (or the Query Cache), but each entity is then hydrated from the L2C if present. If an external process updated the row without going through Hibernate, the ID list is current while the hydrated state is stale — exactly the symptom you describe. The fix must target the L2C, not the Query Cache.

Forcing Fresh Reads for One Query

For a paginated query where you suspect staleness, override the cache mode for that execution:

List<Order> page = session.createQuery(
        "from Order o order by o.id", Order.class)
    .setFirstResult(offset)
    .setMaxResults(pageSize)
    .setCacheMode(CacheMode.REFRESH) // read DB, overwrite L2C entries
    .getResultList();

CacheMode.REFRESH bypasses the L2C on read and writes the freshly loaded state back into the cache, healing it for subsequent readers. CacheMode.IGNORE also bypasses the cache on read but does not update it — useful if you don't trust the current entries but don't want this query to repopulate them either. Neither requires a session clear.

If you already have the entities in hand and only a few are suspect, per-entity refresh is cheaper:

session.refresh(order); // forces SELECT, updates L2C

Or evict the stale entries so the next load repopulates from the database:

session.getSessionFactory().getCache()
    .evict(Order.class, orderId);

How Query Cache Invalidation Actually Works

The Query Cache does not track which rows appeared in which result. Invalidation is driven by update timestamps: each cached query result records which entity types (table spaces) it touches, and any Hibernate-mediated insert, update, or delete against that type bumps the timestamp for the whole space, invalidating all cached queries that reference it — not just the page containing the modified entity.

Two consequences for your scenario:

1. There is no partial invalidation of a paginated result. One modified entity of type Order invalidates every cached query involving Order.
2. Changes made outside Hibernate (another application, direct SQL, a separate non-Hibernate process) bump nothing. The Query Cache keeps serving stale ID lists and the L2C keeps serving stale state until entries expire or are evicted. This is the most common root cause of the pattern you're seeing.

Verifying the Diagnosis

Before changing cache modes, confirm where the staleness enters:

• Enable statistics (hibernate.generate_statistics=true) and watch L2C hit/miss counts alongside query executions. A paginated query with zero database entity loads but high L2C hits confirms hydration from cache.
• Update one returned row via direct SQL, re-run the query, and compare the entity's @Version value against the database. A mismatch confirms L2C staleness rather than a pagination bug.

Caveats

Behavior described here assumes Hibernate ORM 5.x/6.x with a standard region factory (Ehcache, Infinispan, etc.); concurrency strategies matter — nonstrict-read-write has a wider staleness window than read-write even for Hibernate-mediated writes. If external writers are a permanent part of your architecture, the durable fix is a short TTL on that region or coordinating invalidation, not per-query cache-mode overrides.