You configured a JDBC batch size in Hibernate, but a transaction writing several different entity types still produces tiny batches. What do the hibernate.order_inserts and hibernate.order_updates settings do about that, and what do they cost?

## The constraint that creates the problem JDBC batching accumulates parameter sets against one `PreparedStatement`. Hibernate can therefore keep adding to a batch only while consecutive statements share the same SQL string. Any change — different table, different operation, even a different column list for the same table — forces the current batch to be executed and a new one to be started. Realistic write paths interleave. Persisting a hundred orders each with three lines, in natural object order, produces `insert orders`, `insert order_lines`, `insert order_lines`, `insert order_lines`, `insert orders`, … The SQL string alternates constantly, so despite `hibernate.jdbc.batch_size=50` the effective batch size hovers near one and the setting looks broken. ## What the ordering settings do ### `hibernate.order_inserts` When `true`, Hibernate sorts the queued insert actions by entity type before executing the flush. All inserts for one entity type become contiguous, so a single prepared statement can absorb up to `batch_size` of them. The sort is not naive. Hibernate's insert sorter accounts for dependencies between entity types — if `order_lines` carries a foreign key to `orders`, parents must be inserted before children — and orders the type groups accordingly. Where that analysis has limits is **self-referencing** associations, for example a category tree whose rows reference other rows of the same table: within one type group Hibernate cannot always guarantee parent-before-child, and a deferred-constraint-free schema can reject the ordering. When that bites, insert the roots in a separate flush, or make the constraint deferrable if the database supports it. ### `hibernate.order_updates` When `true`, pending updates are sorted by entity type and, within a type, by primary key. The batching benefit is the same as for inserts. The second benefit is subtler and often the real reason to enable it: **deterministic row ordering reduces deadlocks**. Two concurrent transactions that both update rows 7 and 9 will now both take 7 first; without ordering, one may take 7 then 9 while the other takes 9 then 7, and they wait on each other until the database kills one. Ordering does not eliminate deadlocks — different transactions touching different tables in different orders still can — but it removes a common, easily-avoided class. A related setting, `hibernate.order_deletes` (or delete-ordering under `hibernate.order_updates` in some versions), applies the same idea to deletes; deletes are also where foreign-key ordering constraints bite hardest. ## Both default to false This is the most useful fact to carry into an interview. `hibernate.jdbc.batch_size` alone is a half-configuration; for a workload that writes more than one entity type per transaction, the ordering flags are what turn it into real batches. A minimal batching configuration is therefore three properties, not one. ## What it costs - **Sorting work at flush.** Proportional to the number of pending actions; negligible next to the round trips it saves, but not free for enormous flushes. - **Statement order changes.** SQL no longer follows the order of your object manipulations. Code that depended on that ordering — a trigger with side effects, an audit expectation, a deliberately sequenced pair of writes — can behave differently. Hibernate still respects the coarse ordering rules (inserts, then updates, then deletes, in its defined action-type order), so this mainly affects ordering *within* a phase. - **Self-referencing inserts.** As above, the one genuine correctness edge to test. Because the risks are ordering-shaped rather than data-shaped, the safe way to introduce these flags is to enable them and run the write-path integration tests, watching for constraint violations rather than for slowness. ## How to confirm the improvement Statement logging will look identical before and after, since the same statements are prepared either way. Confirm with a proxying datasource or driver-level logging that reports batch size, or by counting round trips at the database. The expected signature after enabling ordering is a small number of large batches per flush instead of many batches of one. ## Interaction with identifier generation Ordering cannot rescue inserts that never reach the flush queue. If the entity uses an identity/auto-increment key, each insert already executed inside `persist()`, so there is nothing left to sort. Fix the identifier strategy first, then ordering and batch size become meaningful.