JPA defines FlushModeType.AUTO and FlushModeType.COMMIT, and Hibernate's native API adds ALWAYS and MANUAL. What does each of those four flush modes do, and why would you move off the default?

## The four modes | Mode | API | Flush at commit | Flush before a query | |---|---|---|---| | `AUTO` | JPA + Hibernate | yes | only if the query could be affected by pending changes | | `COMMIT` | JPA + Hibernate | yes | never | | `ALWAYS` | Hibernate only | yes | always, unconditionally | | `MANUAL` | Hibernate only (`FlushMode.MANUAL`) | **no** | never | In JPA you use `FlushModeType` via `EntityManager.setFlushMode(...)` or `Query.setFlushMode(...)`; the native modes come from `org.hibernate.FlushMode` and are set with `Session.setHibernateFlushMode(...)`. A flush mode set on a query overrides the session-level mode for that query only. ## AUTO — the default, and why it exists The hard problem with write-behind is *read-your-own-writes*. If you change a managed entity and then run a JPQL query, the database still holds the old row, so the query would contradict memory. AUTO solves this by flushing pending changes before the query runs, so query results and the persistence context agree. Hibernate does not flush before *every* query under AUTO — it compares the tables the query reads with the tables the pending actions touch and skips the flush when they cannot overlap. That optimization is what makes AUTO affordable. ## COMMIT — the tempting trap `COMMIT` says: never mind queries, write at commit. The upside is fewer flushes — no mid-transaction writes, so no early row locks and no repeated flush overhead in a loop that alternates writes and queries. The downside is severe. Consider marking an order cancelled in memory and then running `select o from Order o where o.status = 'OPEN'`: under COMMIT the cancelled order is still returned, because the `UPDATE` has not been sent. Application logic that mixes entity mutation and querying silently reads a stale world. Use COMMIT only when you control the whole unit of work and know reads and writes do not overlap. ## ALWAYS — the blunt instrument `ALWAYS` skips the overlap analysis and flushes before every query. It costs performance but is correct by construction. Its main real use is code paths where Hibernate cannot know what a statement touches — typically native SQL or a stored procedure — and you would rather pay for unconditional flushes than reason about it. ## MANUAL — nothing is written unless you say so `MANUAL` (formerly `NEVER`) disables automatic flushing entirely, including at commit. Two uses matter: - **Read-only work.** With MANUAL, an accidental setter on a managed entity cannot turn into an `UPDATE`. Some teams use it as a hard guarantee that a reporting path issues no writes. - **Long conversations.** A multi-step wizard can keep an extended persistence context across requests, accumulate changes, and flush exactly once when the user finally confirms, so intermediate steps never touch the database. The danger is symmetric: if you set MANUAL and forget the explicit `flush()`, the work is *silently discarded* at close. There is no error — just missing data. MANUAL should be a deliberate, narrowly scoped choice, never a global default. ## Choosing Stay on AUTO unless you have a measured reason. If a hot loop shows excessive flush overhead, prefer restructuring the unit of work — do the reads first, then the writes — over switching to COMMIT, because the restructure keeps correctness local instead of making every future query in that unit of work suspect.