How does Hibernate determine which loaded objects changed, why does the UPDATE statement not appear in the SQL log at the moment you call the setter, and what does this detection cost when one transaction has loaded tens of thousands of rows?

## The snapshot When Hibernate hydrates an entity from a result set, it builds the object and also keeps an array of the values it read — the **loaded state**. It lives in the persistence context's bookkeeping entry for that entity, not in the object itself, so application code cannot accidentally modify it. This is the reference point for every later decision about that entity: what changed, and — for features that need old values, such as versionless optimistic locking or certain audit hooks — what the previous values were. ## The comparison At flush, Hibernate walks the managed entities and, for each, compares the current property values against the snapshot. Comparison is delegated to the mapped **type** for each property, not to blanket `equals` on the entity: a basic type compares by value, an association compares by the referenced identifier, an embeddable compares component-wise, a collection is handled by its own persistent-collection snapshot. Any property that reports a difference makes the entity dirty. Nothing dirty means no statement — a transaction that only reads produces no writes, even with thousands of managed entities. ## Write-behind and the action queue A setter never sends SQL. When flush decides an entity is dirty it creates an update action and appends it to the persistence context's action queue; inserts, deletes and collection operations queue up the same way. The queue is drained at flush, which is what people mean by **transactional write-behind**: the database is told about your changes as late as is consistent with correctness rather than statement by statement. Deferral buys concrete things. Multiple mutations to the same entity within a transaction collapse into one UPDATE, because only the end state is compared. Statements of the same shape can be added to a JDBC batch and sent in one round trip instead of many. Prepared statements are reused because the SQL for an entity's update is precompiled and constant (which is also why the default UPDATE lists all columns). And Hibernate retains freedom to order the work sensibly rather than in the arbitrary order your code happened to touch objects. The practical implication for debugging: the line number where SQL appears in the log has almost nothing to do with the line that changed the data. Do not reason about “when did this write happen” from statement order alone; reason about flush boundaries. ## What it costs Two costs, both proportional to what you loaded: - **Memory.** Every managed entity keeps its snapshot, so the persistence context holds roughly twice the field data of the entities in it, plus per-entity bookkeeping. A query that materialises 100,000 rows to compute a sum is paying for 200,000 rows' worth of state. - **CPU at flush.** Each flush re-scans every managed entity, property by property, whether or not anything changed. One flush over 50,000 entities with 20 properties is a million comparisons — and with automatic flush mode, a loop that runs a query per iteration triggers a flush per iteration, turning a linear job quadratic. “The method got slower as the data grew, and profiling points at flush” is the classic symptom. ## How to keep it cheap 1. **Do not load entities you will not modify.** Select the columns you need — a constructor expression into a DTO, or scalar projections — and no entity enters the persistence context at all. This is the single biggest win for report-shaped queries. 2. **Load read-only when you do need objects.** Hibernate's read-only mode (`Session.setReadOnly`, or the `org.hibernate.readOnly` query hint) skips keeping the snapshot, so those entities are never dirty-checked and cannot be updated. Memory and flush cost both drop. 3. **Use a `StatelessSession` for bulk work.** It has no persistence context, no snapshot, no dirty checking and no first-level cache — you issue explicit inserts and updates. Right for migrations and bulk pipelines, wrong for normal domain logic. 4. **Bound the context in batch loops.** Flush and `clear()` every N items so the scanned set stays small and memory is released. Without this, each successive flush is more expensive than the last. 5. **Prefer set-based statements for wholesale changes.** A bulk JPQL `UPDATE` touching a million rows beats loading a million entities — at the cost of bypassing the persistence context, which then holds stale copies and must be cleared. 6. **Consider bytecode enhancement** if the context genuinely must be large: instrumented setters record which attributes changed, so flush no longer walks snapshots. ## The sentence to land Dirty checking is a convenience whose cost scales with *what you loaded*, not with *what you changed*. Keeping persistence contexts small is therefore not tidiness — it is the main lever on flush cost.