What is dirty checking, and why did my entity save without a save() call?

The Answer

Say this in the room. 45 seconds.

• When the persistence context loads an entity it keeps a snapshot — a copy of every persistent field.
• At flush, it compares each managed entity against its snapshot and issues an UPDATE for anything that differs. Nothing calls save.
• So mutating a fetched entity inside a transaction is a write. A setter is a database statement with a delay.
• It only applies to managed entities. A detached one — returned from the service, deserialised, newed — is compared to nothing and silently does not save.
• The cost is that the session holds two copies of everything you load, and flush is O(entities × fields). That is why loading 50,000 rows in one transaction hurts twice.
• @Transactional(readOnly = true) lets Hibernate skip the snapshot. Faster and lighter — and any change you make is then silently discarded.
• By default Hibernate updates every column, not the one you changed. @DynamicUpdate changes that, and it matters more than it sounds.

Understand It

Everything below runs against a model of a persistence context, not Hibernate: a snapshot per loaded entity, a field-by-field comparison at flush, and the managed/detached distinction. Not modelled: SQL, cascades, or flush ordering.

A setter is a write

// A method that reads a product and adjusts a field. There is no save() call
// anywhere in it, and there is no repository in sight.
var session = new Session().seed(new Product(1, "Widget", 1999, 40));

var product = session.find(1);
product.priceMinor = 1799;                  // a discount, applied in memory

System.out.println("  statements before commit : " + session.statements.size());
var issued = session.commit();
System.out.println("  issued at commit         : " + issued);

  statements before commit : 1
  issued at commit         : [update Product set name = ?, priceMinor = ?, stock = ? where id = 1]

One statement before the commit — the select. Then an UPDATE appears out of a method that never asked for one.

This is the single most surprising thing about JPA for people arriving from JDBC, and it is deliberate: the persistence context's job is to make the database match the object graph at the end of the transaction, and it does that by remembering what the graph looked like when it handed it over. Calling save() on an already-managed entity is a no-op — the entity was going to be written anyway.

It follows that there is no such thing as a read-only method that mutates an entity. A helper that normalises a name, a mapper that trims whitespace, a getOrCreate that fills in a default — each of them writes to the database if the entity is managed and the method is inside a transaction.

Notice the statement too: three columns updated, one of them changed. That is the default, and there is a section on it below.

Managed, detached, and read-only

// The same mutation, three times, under three different conditions.
var managed = new Session().seed(new Product(1, "Widget", 1999, 40));
managed.find(1).priceMinor = 1799;
System.out.println("  managed entity      -> " + describe(managed.commit()));

var detached = new Session().seed(new Product(1, "Widget", 1999, 40));
var entity = detached.find(1);
detached.detach(1);                         // returned from the service, session over
entity.priceMinor = 1799;
System.out.println("  detached entity     -> " + describe(detached.commit()));

var readOnly = new Session(true).seed(new Product(1, "Widget", 1999, 40));
readOnly.find(1).priceMinor = 1799;
System.out.println("  readOnly = true     -> " + describe(readOnly.commit()));

  managed entity      -> 1 update: update Product set name = ?, priceMinor = ?, stock = ? where id = 1
  detached entity     -> no statement issued
  readOnly = true     -> no statement issued

Identical code, three outcomes, and the difference is invisible at the point of mutation.

Detached is the one that bites in the other direction. An entity that has left its transaction is an ordinary object; setting a field on it does nothing at all. This is why "I set the value and it didn't save" and "I set the value and it saved without asking" are the same question — both are about whether the object is still managed, and nothing in the code says which.

Read-only is the interesting one. @Transactional(readOnly = true) lets Hibernate skip taking the snapshot, which is a genuine saving on both memory and flush time. The price is that a mutation is not merely unwritten — it is unnoticed, with no error, no warning, and no way to tell from the calling code. That is the right trade for a query method and a trap for anything ambiguous.

What the snapshot costs

// What the session is holding while it does this. One snapshot per entity,
// compared field by field on every flush.
for (int n : new int[] { 10, 1_000, 50_000 }) {
    var session = new Session();
    var rows = new Product[n];
    for (int i = 0; i < n; i++) rows[i] = new Product(i, "p" + i, 100, 1);
    session.seed(rows);
    for (int i = 0; i < n; i++) session.find(i);

    session.find(0).stock = 99;             // change exactly one field
    var issued = session.flush();

    System.out.printf("  %6d loaded -> %d snapshots kept, %d field comparisons, %d update%n",
        n, session.snapshotCount(), session.comparisons, issued.size());
}

      10 loaded -> 10 snapshots kept, 30 field comparisons, 1 update
    1000 loaded -> 1000 snapshots kept, 3000 field comparisons, 1 update
   50000 loaded -> 50000 snapshots kept, 150000 field comparisons, 1 update

Fifty thousand entities loaded, one field changed, and the flush compares a hundred and fifty thousand fields to find it.

Two consequences worth carrying. Memory: the session holds the entity and its snapshot, so a transaction that loads a large result set uses roughly twice what the entities alone would. This is a common cause of an out-of-memory error in a batch job that "only reads".

Time: flush is proportional to what the session has loaded, not to what changed. And flush does not only happen at commit — before most queries, Hibernate flushes so the query sees pending changes. A loop that loads a batch, then queries, then loads another batch pays the whole comparison on every iteration, which is how a batch job becomes quadratic without anything in it looking wrong.

The fixes are the same two things: use readOnly = true where you are not writing, and clear() or a stateless session in a batch so the context does not accumulate.

Every column, not the one you changed

// Change one field. Compare the statement Hibernate builds by default with
// the one it builds under @DynamicUpdate.
for (boolean dynamicUpdate : new boolean[] { false, true }) {
    var session = new Session().seed(new Product(1, "Widget", 1999, 40));
    session.find(1).stock = 39;             // one field, out of three

    var issued = session.flush(dynamicUpdate);
    System.out.printf("  %-16s %s%n", dynamicUpdate ? "@DynamicUpdate" : "default", issued.get(0));
}

  default          update Product set name = ?, priceMinor = ?, stock = ? where id = 1
  @DynamicUpdate   update Product set stock = ? where id = 1

The default builds one UPDATE statement per entity type at startup and reuses it, which is why it lists every column. That is a reasonable trade — the statement is cached and the database parses it once — and it has three consequences people meet without connecting them to this.

Audit triggers fire for columns that did not change, because as far as the database is concerned they were all written. updated_at columns and row-version checks behave the same way. And on a wide table, writing forty columns to change one is real I/O.

@DynamicUpdate builds the statement per flush from the fields that actually differ. It costs statement-cache efficiency and is worth it for wide tables, for tables with column-level triggers, and anywhere concurrent updates to different columns would otherwise conflict.

Reference

The correct implementation, the configuration, and the migration path. Copy from here.

Making writes visible

// This writes to the database. Nothing here says so.
@Transactional
public void applyDiscount(Long id, int newPrice) {
    Product p = repository.findById(id).orElseThrow();
    p.setPriceMinor(newPrice);
}                                     // UPDATE issued here, at commit

// Calling save() adds nothing for a managed entity — but it does tell the
// next reader that a write happens, which is worth something.
@Transactional
public void applyDiscount(Long id, int newPrice) {
    Product p = repository.findById(id).orElseThrow();
    p.setPriceMinor(newPrice);
    repository.save(p);               // redundant to JPA, informative to humans
}

There are two schools on the redundant save(). It is genuinely a no-op, and it also stops a reviewer having to know this mechanism to see that the method writes. Pick one and be consistent; what is not defensible is a codebase where its presence or absence means nothing.

Read-only, and what it actually turns off

// Skips the snapshot, so no dirty checking and no flush. Lighter and faster,
// and any mutation is silently discarded.
@Transactional(readOnly = true)
public List<ProductView> search(String term) { ... }

# Hibernate also honours this at the query level.
# In a repository: @QueryHints(@QueryHint(name = HINT_READ_ONLY, value = "true"))

Use it on every query method. The saving is real, and the risk — a lost update — only exists in methods that were mutating an entity while claiming to be a read, which is a bug either way.

Note it does not make the transaction read-only at the database level on every provider; on PostgreSQL Spring does set the JDBC connection read-only, on others it may be advisory. If you need the database to refuse writes, say so explicitly.

Batch work, where the context is the problem

// The context accumulates every entity, and flushes compare all of them.
@Transactional
public void reprice(List<Long> ids) {
    for (int i = 0; i < ids.size(); i++) {
        Product p = repository.findById(ids.get(i)).orElseThrow();
        p.setPriceMinor(recalculate(p));
        if (i % 50 == 0) {
            entityManager.flush();
            entityManager.clear();    // detach everything; snapshots go with it
        }
    }
}

// Or skip the persistence context entirely for a pure batch.
StatelessSession session = sessionFactory.openStatelessSession();
// No first-level cache, no dirty checking, no cascades. You issue every write.

-- Or do not load the rows at all. This is one statement and no snapshots.
update Product p set p.priceMinor = p.priceMinor * 0.9 where p.category = :c

The bulk UPDATE is the right answer far more often than people reach for it. Its cost is that it bypasses the persistence context — entities already loaded keep their stale values, and no entity callbacks or version increments happen — so it wants a clear() afterwards and care with optimistic locking.

Dynamic update

@Entity
@DynamicUpdate                        // build the UPDATE from the changed fields
class Product { ... }

Worth it for wide tables, for tables with column-level audit triggers, and where two transactions routinely change different columns of the same row. Not worth it for narrow tables that are written often, where the cached statement is the better trade.

Which mode when

Scenarios

Real situations, with the decision and the argument.

1. A field changed in production and nobody can find the save().

There will not be one. Look instead for a method that fetches the entity and passes it somewhere that mutates it — a mapper, a validator that normalises, a helper that fills a default. Anything mutating a managed entity inside a transaction is a write.

@DynamicUpdate helps the investigation as much as the performance: with it on, the SQL log shows which column actually changed, rather than an UPDATE naming every column on every write. Turning it on temporarily is a reasonable diagnostic step.

2. "I set the value and it didn't save."

The mirror image, and the same underlying question: the entity was detached. It came back from a service method whose transaction had already ended, or from a cache, or from deserialisation.

The confusing part for the person reporting it is that both behaviours exist in the same codebase — one place saves without asking, another silently does not — and neither is visible at the point of mutation. The durable fix is not to remember which is which but to stop passing entities across the boundary: a DTO cannot be accidentally dirty-checked or accidentally not.

3. A batch job runs out of memory, and it only reads.

It does not only read — it accumulates. The persistence context holds every entity it has loaded plus a snapshot of each, so a transaction that walks a large table uses about twice the entities' own footprint and never releases any of it until commit.

flush() and clear() every few hundred rows fixes it, or a StatelessSession if there is nothing to write. And if the job is genuinely read-only, readOnly = true removes the snapshot half of the cost for free.

4. Someone proposes readOnly = true on every service method.

Right for query methods, dangerous as a blanket rule. On a method that mutates an entity, the change is not rejected — it is silently ignored, with no error to notice in testing and nothing in the log.

Apply it deliberately per method, and treat any method it breaks as a finding rather than a reason to remove it: a method that was mutating an entity while presenting itself as a read is a bug that this setting has just surfaced.

5. An audit table is full of rows where nothing changed.

Column-level triggers firing because the default UPDATE writes every column. From the database's point of view all forty were assigned, whether or not the value differs.

@DynamicUpdate fixes it at the source. Before adding it everywhere, note the trade — statements are built per flush rather than cached — so apply it to the wide, audited tables where it earns its cost, not globally.

Interviewer's Next Move

The question after the question. This is what the round is actually testing.

1. "What is dirty checking?" The persistence context keeps a snapshot of every entity it loads and compares it against the live object at flush time, issuing an UPDATE for whatever differs. It is why a setter on a managed entity is a database write.

2. "So why did my entity save without a save() call?" Because it was managed and inside a transaction. save() on an already-managed entity is a no-op — the entity was going to be written at flush regardless.

3. "When does the flush happen?" At commit, and before most queries, so the query sees pending changes. That second one surprises people: a read in the middle of a method can trigger writes from earlier in it.

4. "When does it not happen?" When the entity is detached — returned from a service, deserialised, constructed — because there is no snapshot to compare against. And under readOnly = true, where Hibernate skips the snapshot entirely.

5. "What does dirty checking cost?" Two copies of every loaded entity in memory, and a flush proportional to what the session has loaded rather than to what changed. Loading fifty thousand rows to change one field compares every field of all of them.

6. "How do you make a batch job survive that?" flush() and clear() every few hundred entities, or a StatelessSession, or — usually best — do not load the rows at all and issue a bulk update statement instead.

7. "What does @Transactional(readOnly = true) actually do?" Lets Hibernate skip the snapshot, so there is no dirty checking and no flush. It is a real saving, and it means a mutation in that method is discarded silently.

8. "Which columns does the UPDATE set?" All of them, by default — one cached statement per entity type. @DynamicUpdate builds it per flush from the changed fields, which matters for wide tables and for column-level audit triggers.

9. "Why not return entities from a service?" Because whether a setter on them writes depends on state the caller cannot see. Inside the transaction it writes; outside it does nothing. A DTO removes the ambiguity.

Code traps

Trap A — predict before you run:

@Transactional(readOnly = true)
public ProductDto get(Long id) {
    Product p = repository.findById(id).orElseThrow();
    p.setName(p.getName().trim());        // tidy up a legacy value
    return mapper.toDto(p);
}

Trap B:

@Transactional
public void deactivateAll(List<Long> ids) {
    for (Long id : ids) {
        Product p = repository.findById(id).orElseThrow();
        p.setActive(false);
    }
}

Trap C:

@Transactional
public void rename(Long id, String name) {
    Product p = repository.findById(id).orElseThrow();
    p.setName(name);
    if (!isValid(name)) {
        return;                            // give up without saving
    }
    auditLog.record(id, name);
}

Common wrong answers

Check Yourself

Q1. A method fetches an entity, changes one field, and never calls save(). Does the change persist?

Q2. A read-only batch job runs out of memory. It does not write anything. Why?

Q3. Why does an audit trigger fire on columns nobody changed?

Practice