NHibernate Flush— How it works?

Question

I am kind of confused on how Flush ( and NHibernate.ISession) in NHibernate works.

From my code, it seems that when I saved an object by u

Answer 1

NHibernate will only perform SQL statements when it is necessary. It will postpone the execution of SQL statements as long as possible.

For instance, when you save an entity which has an assigned id, it will likely postpone the executin of the INSERT statement. However, when you insert an entity which has an auto-increment id for instance, then NHibernate needs to INSERT the entity directly, since it has to know the id that will be assigned to this entity.

When you explicitly call flush, then NHibernate will execute the SQL statements that are necessary for objects that have been changed / created / deleted in that session.

Flush

Answer 2

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.