Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
JPA can persist changes to an entity without a separate update call—but only while that entity is managed by an active persistence context. JPA detects changes to managed state, then synchronizes them during a flush. A setter changes the Java object immediately; it does not guarantee an immediate SQL update or a committed transaction.
Why JPA can save a change without an update call
The Jakarta Persistence EntityManager API describes no explicit update operation for an entity that is already managed. While the entity remains associated with a persistence context, changes to its persistent fields or properties are automatically detected. This is commonly called dirty checking.
For example, if an entity was loaded through an EntityManager and remains managed, changing one of its persistent properties does not require a separate update call. The change first exists in the persistence context’s in-memory state. The provider synchronizes it with the database later, through a flush.
Dirty checking and flushing are different stages
1. A managed entity changes in memory
When application code changes a persistent field or property on a managed entity, JPA can detect that the entity’s state has changed. That detection does not itself promise that SQL runs at that moment.
#1 Best Overall
2. Flush synchronizes pending changes
Flushing synchronizes pending persistence-context changes with the database. The application can request it with EntityManager.flush(); otherwise, flush timing depends on the flush mode, queries, provider behavior, and transaction completion.
3. Commit completes the transaction
A successful flush is not the same as a committed transaction. Flush performs synchronization work; commit is the transaction boundary. A later database or constraint failure can still affect whether the transaction succeeds.
When JPA flushes changes
The Jakarta Persistence 3.2 specification defines AUTO and COMMIT flush modes. Both operate in the context of transactions: a provider must not flush changes when no transaction is active or when the persistence context has not joined that transaction.
| Flush mode | What JPA specifies |
|---|---|
AUTO |
Before processing a query, the provider must ensure that changes which could affect its results are visible. It may do this by flushing. Pending changes are also flushed at transaction commit. |
COMMIT |
Flushing occurs at transaction commit, though the provider may flush earlier. The effect of unflushed changes on query results is unspecified. |
These rules do not mean every query triggers a flush. The requirement in AUTO concerns changes that could affect that query’s results; the provider chooses how to ensure the required visibility.
A newer, version-specific mode
The Jakarta Persistence 4.0 nightly API also lists EXPLICIT mode, where each flush is explicitly requested with EntityManager.flush(). This is a nightly API detail, not a mode to assume is available in older JPA versions. See the Jakarta Persistence 4.0 nightly EntityManager API.
Hibernate’s additional scheduling details
Hibernate’s stable user guide describes its AUTO mode as flushing before transaction commit, before JPQL/HQL queries that overlap queued entity actions, and before native SQL queries without registered synchronization. Its COMMIT mode tries to defer flushing until commit but may flush earlier. These are Hibernate-specific details, not a query schedule guaranteed by JPA for every provider. See the Hibernate ORM User Guide.
Rank #4
Cases where changing an object is not enough
The entity is detached
Automatic change detection applies while an entity is associated with an active persistence context. If an entity is detached, changing its Java fields alone is not equivalent to changing managed state. The application must arrange for its state to be merged or otherwise managed before expecting persistence-context synchronization.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →The transaction is absent or the context has not joined it
A provider must not flush when there is no active transaction or the persistence context has not joined the transaction. With an application-managed context created outside a transaction, an explicit join may be needed depending on how that context is managed.
Best Value
Only the inverse side of a relationship changed
In a bidirectional relationship, update the owning side: that side determines the relationship update persisted to the database. Changing only the inverse side can leave the stored relationship unchanged. See the Jakarta Persistence 3.2 specification.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A practical way to reason about a “silent save”
- Check the entity state: Was it loaded, persisted, or otherwise associated with the current persistence context, and is it still managed?
- Check the transaction: Is a transaction active, and has the persistence context joined it?
- Check the relationship: For a bidirectional association, did the code update the owning side?
- Check synchronization timing: Is a flush explicitly requested, prompted by query visibility under
AUTO, or due at transaction commit? - Keep the outcomes distinct: A changed Java object, a flushed database update, and a committed transaction are separate states.
This explanation concerns ordinary changes to managed entities. Bulk JPQL and native update operations have different semantics and are not covered by the dirty-checking rules described here.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
