L1 vs L2 Cache Scopes

## What the first-level cache is The "first-level cache" is not a separate component you configure. It is the persistence context: the map of managed entities that an `EntityManager` (Hibernate `Session`) keeps for its lifetime. Its key is the pair (entity type, identifier); its value is the managed Java instance plus a snapshot of the state as loaded. Because of that map, the second `find` for the same identifier never reaches the database. It is a hash lookup returning the object already in memory. ## The identity guarantee Within one persistence context there is exactly one instance per row. This is the property that makes an ORM usable: - Two code paths that load customer 1 by different routes — a direct `find`, a JPQL query, navigating `order.getCustomer()` — receive the same object. A change made in one place is visible in all of them. - Reference equality (`==`) works as an identity test for managed entities in the same session, which is why `equals`/`hashCode` on entities is subtle only once instances are detached or compared across sessions. - Dirty checking has something to compare against: at flush Hibernate walks the managed entities, diffs each against its loaded snapshot, and generates UPDATEs only for what actually changed. ## Repeatable read at the session level Read a row, and no later read in that session will show you a different version of it, regardless of what other transactions committed, because the later read never leaves memory. That is a convenience, not a database isolation level; the freshness of the value is whatever it was at first load. If you need current state, `em.refresh(entity)` re-reads that row and overwrites the in-memory instance (discarding any unflushed changes to it). ## What it does not cover - **Queries still run.** A JPQL query always goes to the database, because the persistence context is keyed by identifier and cannot answer arbitrary predicates. What it does do is deduplicate the *results*: if a returned row belongs to an entity already managed, Hibernate discards the freshly read row data and hands you the existing instance. So a stale managed instance can "shadow" newer database values. - **Scalar projections** (`select c.name from Customer c`) are not entities and are not stored in the context at all. - **Nothing is shared between sessions.** Two concurrent requests each have their own persistence context and their own instances; the first-level cache never helps another user. ## Lifecycle and the batch pitfall Entries accumulate: every entity loaded or persisted stays until removed. In a long-running batch that reads a million rows in one session, all of them stay reachable, along with their snapshots, so memory grows roughly at twice the entity footprint and flush time grows because dirty checking scans everything. The standard remedy is to work in chunks, `flush()` then `clear()` after each chunk, so the context stays small. `detach(entity)` handles the single-object case; `close()` discards everything. One caution: `clear()` discards pending changes without writing them, so flush first when the writes matter. ## Relationship to the second-level cache Different scope entirely. The first-level cache is per session, always on, stores live objects, and dies with the session. The second-level cache is per `SessionFactory`, opt-in, shared by all sessions, and stores state rather than objects. A `find` consults the persistence context first and only then the shared cache and finally the database. ## How to answer this in an interview Give the concrete answer first — one SELECT, the same reference — then name the mechanism (persistence context as an identity map), then the two guarantees (identity, session-level repeatable read), then the limits (queries still execute, nothing shared between sessions, memory growth in long sessions). That is a complete junior-to-middle answer.