Why is NHibernate AutoFlush check so expensive?

Question

In practice we are finding the default NHibernate (v2.0 & 2.1) FlushMode=Auto to be extremely expensive. Reviewing the NHibernate source suggests that the algorithms for determining what needs to be flushed rely on brute-force of looping through all entities in session, and this occurs for every query run in a transaction.

In some production scenario with updates on many items, with multiple queries we have seen the process 100 times longer with FlushMode=Auto compared to FlushMode=Commit.

Any thoughts/advice/best practices for usage of FlushMode when performing 'complex' session logic involving multiple updates, multiple queries etc.

Any ideas on optimizing the AutoFlush algorithms in nHibernate?

Answer 1

This slowness is a known issue and is tracked in NH Jira as NH-1365

There are three flush modes in NH:

• FlushMode.Auto = Flush when needed (on commit and before queries, if needed). This is the default.
• FlushMode.Commit = flush on commit of NH transaction only
• FlushMode.Never = never flush (until Flush is called). This will still go to DB on insert of entities that use native (identity) PK generator.