In many cases you don't have to care when NHibernate flushes.
You only need to call flush if you created your own connection because NHibernate doesn't know when you commit on it.
What is really important for you is the transaction. During the transaction, you are isolated from other transactions, this means, you always see your changes when you read form the database, and you don't see others changes (unless they are committed). So you don't have to care when NHibernate updates data in the database unless it is committed. It is not visible to anyone anyway.
NHibernate flushes if
- you call commit
- before queries to ensure that you filter by the actual state in memory
- when you call flush
Example:
using (session = factory.CreateSession())
using (session.BeginTransaction())
{
var entity = session.Get<Entity>(2);
entity.Name = "new name";
// there is no update. NHibernate flushes the changes.
session.Transaction.Commit();
session.Close();
}
The entity is updated on commit. NHibernate sees that your session is dirty and flushes the changes to the database. You need update and save only if you made the changes outside of the session. (This means with a detached entity, that is an entity that is not known by the session).
Notes on performance: Flush not only performs the required SQL statements to update the database. It also searches for changes in memory. Since there is no dirty flag on POCOs, it needs to compare every property of every object in the session to its first level cache. This may become a performance problem when it is done too often. There are a couple of things you can do to avoid performance problems:
- Do not flush in loops
- Avoid serialized objects (serialization is required to check for changes)
- Use read-only entities when appropriate
- Set mutable = false when appropriate
- When using custom types in properties, implement efficient Equals methods
- Carefully disable auto-flush when you are sure that you know what you are doing.