NHibernate FlushMode.Auto Produces Divergent Auto-Flush Decisions Across Query APIs

NHibernate's automatic flush behavior under FlushMode.Auto is documented as a heuristic that flushes pending changes before a query only when the session determines the query might touch the same entity or table spaces. In workflows that mix HQL, Criteria, QueryOver, and LINQ against the same transaction, developers face an unresolved consistency decision: whether the implicit heuristic is reliable enough for read-after-write scenarios, or whether explicit control is required.

The uncertainty is compounded because the heuristic is not guaranteed to be uniform across query APIs. Logically equivalent operations may trigger different flush decisions, and the best-effort nature of query-space overlap detection means some queries may not see pending inserts or updates without an explicit flush. Behavior may also vary across NHibernate versions, so assumptions drawn from one release may not hold in another. Switching to FlushMode.Commit or FlushMode.Manual changes the consistency model, while changing modes mid-transaction risks inconsistent in-transaction snapshots.

Which query APIs are documented to share identical auto-flush semantics under FlushMode.Auto across current NHibernate versions, and what criteria should teams use to weigh the implicit heuristic against explicit session.Flush() calls or alternative flush modes when read consistency within a transaction is required?