Question

I am wondering under what circumstances the following NHibernate code could fail:

var session = NHibernateSessionManager.CurrentSession;

var foo = session.Linq<Foo>.ToList()[0];

foo.SomeProperty = "test";

session.SaveOrUpdate(foo);

var reloadedFoos = session.Linq<Foo>
                         .Where(x => x.SomeProperty == "test");

Assert.That(reloadedFoos.Count > 0);

The Assert statement always fails.

If I manually call session.Flush after SaveOrUpdate, then the select query succeeds, however I thought that we did not have to manually call flush? It was my understanding that NHibernate should be smart enough to realise that Foo has been updated, so the second select query should succeed.

Watching the SQL that is generated, it appears the second select query’s SQL is executed before the first SaveOrUpdate’s sql.

In fact, if I wrap the entire method in a transaction, then it succeeds:

using(NHibernateSessionManager.CurrentSession.BeginTransaction()
{
    // Same code as above
}

Now the SaveOrUpdate’s sql will execute before the Linq.Where sql. This is a little strange, as I do not have to even commit the transaction in between.

What is going on?

Answer 1

I recommend you leverage NHibernate transactions. It’s entirely possible that, without their use, NHibernate has no way of determining when to issue your SaveOrUpdate call.

You’ll find that even read-only statements perform better when using transactions. Please see http://nhprof.com/Learn/Alert?name=DoNotUseImplicitTransactions for further details.

For example:

using(var session = NHibernateSessionManager.CurrentSession)
{
  using(var transaction = session.BeginTransaction())
  {
    var foo = session.Linq<Foo>.ToList()[0];

    foo.SomeProperty = "test";

    session.SaveOrUpdate(foo);
    transaction.Commit();
  }
}