Does a JPQL or HQL query read from the session's first-level cache? Explain what Hibernate does when a query returns a row whose entity instance is already present in the persistence context with different in-memory values.

## Two different questions "Does a query use the first-level cache?" conflates two things: 1. **Can the query be answered without SQL?** No. The persistence context is an identity map keyed by primary key; it cannot evaluate `WHERE status = 'NEW' ORDER BY created`. Every JPQL/HQL/Criteria/native query goes to the database. (A separate, optional *query cache* exists but is off by default and is not the first-level cache.) 2. **Does the persistence context affect what the query returns?** Very much so, on result hydration. ## Flush before the query Under Hibernate's automatic synchronisation, before executing a query that touches tables with pending changes, Hibernate flushes so the SQL sees your uncommitted work. Without that, a query would miss the row you just persisted in the same transaction. So step one of a query is often a burst of INSERT/UPDATE/DELETE you did not explicitly ask for. ## Hydration and the identity map For each row in the result set, Hibernate reads the identifier and looks the key up in the persistence context: - **Miss** — it hydrates a new instance from the column values, registers it in the context together with a snapshot, and returns it. - **Hit** — it returns the *existing managed instance* and **discards the freshly read values**. That second rule is the whole answer to the interview question. It exists to preserve the identity guarantee: one instance per row per session. Overwriting the instance would silently destroy unflushed changes the application has made and would break every other reference already pointing at that object. ### Case A — your own unflushed change ``` Order o = em.find(Order.class, 1L); o.setStatus(CANCELLED); // not flushed if flushing is suppressed List<Order> news = em.createQuery("select o from Order o where o.status = 'NEW'", Order.class) .getResultList(); ``` With automatic flushing on, the UPDATE goes out first and the row no longer matches, so the query returns nothing — consistent. But if flushing is suppressed for that query, the database still holds `NEW`, the row comes back, and hydration hands you the very instance whose status you set to `CANCELLED`. You then hold a "NEW orders" list containing a cancelled order. Nothing is broken; the query filtered on database state while the object shows session state. ### Case B — another transaction's committed change Your session loaded order 1 with `total = 100`. Another transaction commits `total = 120`. Your query re-reads the row and sees 120 in the result set — and then discards it, returning your instance that still says 100. The session gives you application-level repeatable reads whether or not the database isolation level does. ### Case C — scalar projections ``` em.createQuery("select o.total from Order o where o.id = 1", BigDecimal.class).getSingleResult(); ``` No entity is hydrated, so no identity map lookup happens; you get the raw database value, 120. Now the same session reports 100 through the entity and 120 through the projection. Every "my DTO and my entity disagree" bug of this shape has this cause. ## Getting fresh values on purpose - `em.refresh(entity)` — SELECT and **overwrite** the managed instance's fields, discarding unflushed local changes. Object identity is preserved, so all existing references see the new values. - `em.detach(entity)` (or `clear()`) then re-query — you get a *new* instance with fresh values; the old reference becomes a stale detached object, which is often worse than refreshing. - A query hint or lock mode requesting a refresh (`LockModeType.PESSIMISTIC_*` re-reads under a lock, and Hibernate's `CacheMode.REFRESH` targets the second-level cache, not this one). There is no flag that makes ordinary query hydration overwrite managed instances — and there should not be, because it would break unflushed work. ## Practical rules 1. Do not use a query as a way to "re-read" an entity you already hold; use `refresh()`. 2. If a long transaction must see other transactions' committed changes, plan explicit refresh points, or keep the unit of work short. 3. When a projection and an entity disagree in the same session, check whether the entity is managed and stale rather than suspecting the SQL. 4. Expect a query to trigger a flush; if you see unexplained UPDATEs just before a SELECT in the log, that is the automatic synchronisation doing its job.