Loading published curriculum…

14 · Hibernate and Spring Data JPA in depth / LESSON 64 OF 102

Dirty checking, flush, and commit

SQL synchronization and transaction commitment are different events.

Before this lesson: Entity states and the persistence context

Understand the topic

Hibernate detects changes to managed entities and schedules SQL at flush. Flush may occur before a query or at commit. An explicit flush sends pending SQL but does not make the transaction durable or prevent later rollback.

Constraint failures may appear at flush rather than at a setter or save call. Keep transaction boundaries around the complete use case and translate failures after the transaction outcome is known. Avoid unnecessary flush calls inside loops.

EXAMPLE · JAVA

Persistence experiment

// Inside an active transaction using the existing Task entity.
Task task = entityManager.find(Task.class, 1L);
entityManager.flush();
// SQL is synchronized, but rollback is still possible.
entityManager.clear();
System.out.println(entityManager.contains(task));

What to expect

Prints false after clear; flushing did not commit and clearing detached the managed instances.

YOUR TURN

Put it into practice

  1. 01Update a managed entity, flush, then deliberately roll back.
  2. 02Read from a new transaction after the rollback and inspect SQL logs.
  3. 03Verify: The original value remains despite an UPDATE having been sent before rollback.

Pass a quiz or complete a lab to check today’s streak. Each lesson counts once per day, including when you review it later.

UNDER THE HOOD

Build the mental model

SQL synchronization and transaction commitment are different events.

  1. 01Hibernate detects changes to managed entities and schedules SQL at flush. Flush may occur before a query or at commit. An explicit flush sends pending SQL but does not make the transaction durable or prevent later rollback.
  2. 02Constraint failures may appear at flush rather than at a setter or save call. Keep transaction boundaries around the complete use case and translate failures after the transaction outcome is known. Avoid unnecessary flush calls inside loops.
  3. 03Trace the example: Prints false after clear; flushing did not commit and clearing detached the managed instances.

A mistake worth avoiding

A constraint exception appears later than the repository call that caused it.

DEBUGGING ROOM

Something broke. Where do you look?

A constraint exception appears later than the repository call that caused it.

Before revealing the diagnosis, write down your first investigation step.

CHECK YOUR UNDERSTANDING

Does flush guarantee a committed change?

Choose one answer

BUILD IT YOURSELF

Update a managed entity, flush, then deliberately roll back.

  1. 1.Update a managed entity, flush, then deliberately roll back.
  2. 2.Read from a new transaction after the rollback and inspect SQL logs.
  3. 3.Reproduce this failure, then repair it: A constraint exception appears later than the repository call that caused it.

Acceptance checklist

Lab completion is your self-report. Knowledge checks do not certify project quality.

RETRIEVE IT FROM MEMORY

Does flush guarantee a committed change?

Revisit this lesson in three days after a successful check or lab.

Ready for the next step?

The original value remains despite an UPDATE having been sent before rollback.

Reading is separate from passing a knowledge check or completing a lab.

Go deeper · official references