So I’m pretty sure I’ve found a bug.
Add the attached test to FooBarTests.cs

1 Run it as it is and it works.
2 Modify the code by adding ! before SHOULDNT_THIS_BE_ENOUGH (that is choose the Evict solution).

It seems that even if I’ve re-read the One instance getting it to understand that its version (V) is 1, 0 is used in the update statement. The 0 was the original value when first reading the instance. Run the code.

Regards, Ingo

[Test]
public void IsThisABug()
{
long key;
using (ISession s = OpenSession())
{
One one = new One();
one.Manies = new HashedSet();
s.Save(one);
s.Flush();
key = one.Key;
}

// Intending to update
ISession s1 = OpenSession();
One o1 = (One)s1.Get(typeof(One), key);
Assert.IsNotNull(o1);
Assert.AreEqual(0, o1.V);

// Update in another session beats u to it
ISession s2 = OpenSession();
One o2 = (One)s2.Get(typeof(One), key);
Assert.IsNotNull(o2);
o2.X = 2;
s2.Flush();
Assert.AreEqual(1, o2.V);
s2.Dispose();

// slow as I am, now I'm gonna try to update
o1.X = 1;
try
{
s1.Flush();
Assert.Fail("Should fail");
}
catch(NHibernate.StaleObjectStateException)
{
// oh, well. Prepare to retry
#if SHOULDNT_THIS_BE_ENOUGH
s1.Evict(o1);
#else
s1.Dispose();
s1 = OpenSession();
#endif
}

// let's read it from db again and retry the update
o1 = (One)s1.Get(typeof(One), key);
Assert.AreEqual(1, o1.V);
o1.X = 1;
// with Evict, this fails again with StaleObjectStateException
// note that o1.V == 1 is however correct with Evict
s1.Flush();
Assert.AreEqual(2, o1.V);

s1.Dispose();

using (ISession s = OpenSession())
{
s.Delete( "from o in class NHibernate.DomainModel.One" );
s.Flush();
}
}

Bugs arising from reusing a session that caused an exception are not considered to be bugs. Don't reuse sessions after exceptions.

Ah, I see. I wasn’t aware of this limitation. Sure, I’m aware of the problems with inconsistency between cached objects (those in the session’s Identity Map, IM) and objects in the database. I fully understand that. But in the case where I first encountered this “what I thought was a bug” I knew that I only had one object in the session. I tried doing an Evict followed by a Get and I could for certain see that the object was fetched from the database again. And for sure, it was fetched with its persisted version number. Still, the following save uses not that version number but the prior version number. (This was also shown in the test routine that I supplied you with.) My conclusion is, if I dare, that NH stores the version number at a “side location” when first retrieving an object but fails to clear that when evicting the same object. A classical problem of redundancy?

So, sure, the rule is not to keep using the session object after an exception (stemming from NHibernate, I only can assume), but you have to agree that the scenario described above has somewhat of a bad smell to it.

Anyway, thank you for the quick answer. Now I know what to do. I actually already did that in the test but felt that killing the session was, well, overkill :-)

Regards, Ingo