Nobody called save, but the UPDATE still went to the database. Explain how that happened.
Hibernate dirty checking tracks a managed JPA entity through the persistence context. At flush the provider compares the entity against its loaded snapshot and writes an UPDATE for whatever differs, so mutating a managed object inside a transaction is itself the instruction to persist. Use this spring data jpa answer to show the decision, trade-off, and evidence rather than a memorised definition.
Answer
Short answer
Hibernate dirty checking in Spring Data JPA means a loaded entity is tracked as managed inside the persistence context. When the transaction flushes, Hibernate compares the current object with its loaded snapshot and sends an UPDATE if mapped fields changed. No explicit save call is needed; changing a managed entity inside the transaction is enough.
Was this answer helpful?
Likely follow-ups
- Why does deleting a row and inserting one with the same unique key in a single transaction fail?
- What exactly does @Transactional(readOnly = true) change, in Hibernate and in JDBC?
- Why does calling persist on a detached entity throw, when merge does not?
- How does @Version turn a stale detached entity into a failure rather than a lost update?
Related questions
- You pass a thousand new entities to saveAll and the database sees a thousand separate inserts. How do you get them batched?hardAlso on spring-data-jpa and jpa5 min
- A Spring Data repository method looks like one clean line, but the endpoint issues several hundred queries per request. How do you diagnose the N+1, and what would you actually change?hardAlso on spring-data-jpa and hibernate4 min
- This endpoint logs one query per row. Why are you seeing N+1 queries, and how do you fix them?mediumAlso on jpa and hibernate6 min
- Your lazy-loading proxy works until someone calls equals or getClass on it. What breaks, and how do you design a proxy that survives it?hardAlso on hibernate5 min