intermediateThe Persistence Context — First-Level Cache, Dirty Checking & Flush

Why does mutating a managed entity's field get persisted even without calling save() or update()?

Hibernate's dirty checking compares a managed entity's current field values against a snapshot taken when it was loaded, at flush time. If any field differs, Hibernate generates an UPDATE for it automatically — the entity is already tracked ('managed') by the persistence context, so no explicit save call is needed to trigger persistence.

This is a Pro chapter

Sign in, then upgrade to Pro or Power to unlock this and the full Spring Ecosystem Mastery library.

Why does mutating a managed entity's field get persisted even without calling save() or update()?

Next Step

Continue to What's the difference between a flush and a commit?← Back to all Spring Data JPA & Hibernate Mastery questions