How does a Unit of Work typically detect which loaded objects are 'dirty' (changed) so it knows what to write back to the database, and what role does the identity map play in that?

## What dirty detection is **Dirty detection** is the mechanism a Unit of Work uses to decide which of the objects it's tracking need a write-back to the database, without requiring the developer to explicitly call `update()` every time a field changes. Two implementation strategies dominate. - **The first, snapshot diffing,** is what Hibernate and most JPA providers use: when an entity is loaded, the persistence context stores a copy of its field values alongside the live object. At flush time — just before a query that might depend on pending changes, or at transaction commit — the Unit of Work walks every tracked entity, compares its current field values against the stored snapshot, and builds an `UPDATE` statement containing only the columns that actually differ. - **The second strategy, instrumented or explicit dirty marking,** avoids the comparison cost by intercepting mutation at the source: a dynamic proxy, bytecode-woven setter, or framework convention flags the object the instant a field changes, so the Unit of Work already knows its dirty set without diffing anything at flush time. .NET's Entity Framework historically used snapshot-style change tracking by default but also supports a notification-based mode using `INotifyPropertyChanged` for the second style. ## The identity map The identity map is the structure that makes either strategy trustworthy. It is a per-transaction (or per-session) cache keyed by an object's identity — typically its entity type plus primary key — that guarantees loading the same database row twice within one Unit of Work returns the exact same in-memory object reference, **not two independent copies**. Without it, two different parts of the application code could each load 'their own' copy of the same customer row, mutate different fields on their respective copies, and the Unit of Work would have no way to reconcile which mutations are real or to avoid issuing two conflicting `UPDATE` statements for the same row. With an identity map, there is exactly one in-memory representative of each row, so dirty checking always has a single, unambiguous object to compare against its snapshot. ## Why both pieces exist Both pieces exist to solve a correctness-and-efficiency problem at the same time. - **Correctness:** mutations scattered across a large object graph, potentially touched by several collaborating code paths in the course of one business operation, need to converge to one consistent, final state before anything is written — the identity map is what makes 'the same row' actually mean the same object. - **Efficiency:** without dirty tracking, an ORM would have to either write back every loaded object regardless of whether it changed (enormous waste) or force developers to manually track and call `save()` on each mutated object (error-prone, easy to forget one). ## The trade-offs The trade-offs are real on both sides. | Strategy | What it costs | |---|---| | **Snapshot diffing** | Costs memory — roughly double, since both the live object and its original-state snapshot sit in memory for the lifetime of the session — and costs CPU at flush time proportional to the number of tracked entities, which becomes noticeable when a Unit of Work has accumulated thousands of loaded rows in a batch job. | | **Instrumented dirty marking** | Avoids the diff cost but adds proxying/bytecode-generation complexity, and sometimes misses mutations that bypass the instrumented setters entirely (e.g., reflection-based frameworks, or mutating a returned collection in place). | ## Failure modes in production In production, failures cluster around two patterns. 1. **First, detached-entity edits:** an entity loaded in one session, serialized out (e.g., to a web layer), mutated there, and later re-attached to a new session without an explicit merge — the new session has no snapshot for that object's prior loaded state, so dirty-detection and identity-map guarantees silently don't apply the way a developer expects, sometimes producing a full-row `UPDATE`, sometimes an error, sometimes a lost update if two edits interleave. 2. **Second, a session kept alive far too long** accumulates an identity map that never gets cleared, ballooning memory in long batch processes (a classic 'session grew to millions of entities and OOM'd' incident) and returning stale cached objects to code that expected fresh reads. ## Where it shows up A concrete example: Hibernate's `Session` is both the Unit of Work and the identity map in one object. Calling `session.get(Customer.class, 42L)` twice within the same session returns the identical Java object reference both times — guaranteed by the identity map — and any field mutation on that object is picked up by snapshot-diff dirty checking at the next flush, with zero explicit `save()` call required.