In case anyone was wondering, I figured out the problem. I am trying to map a legacy database that uses version columns that are nullable. NHibernate threw exceptions when I defined the nullable types in my POCOs and the NHibernate XML (even though the manual stated that they were supported -- so likely a bug) so I defined them as "int". However, I didn't notice that some rows (very few - likely mistakes, or cases where someone hand-edited the data) in the database indeed have NULL values for the version column. If a query ever cached one of these NULL values, and NHibernate subsequently performed a dirty check, it will throw this exception.
If I have time, I'll write up a test case and try patching the code so NHibernate supports nullable version columns better. I think if NHibernate treated NULL version columns as if they had the value 0, this would fix the problem. Regards, Mike On Tue, Nov 9, 2010 at 5:30 PM, Mike Pontillo <[email protected]> wrote: > Greetings, > > I am using NHibernate 3.0.0 beta 2, and am trying to evolve some > prototype code that was using the "session per call" anti-pattern to > use a "session per request" approach. I soon noticed that after > implementing the session sharing, my unit tests started failing with > the following exception: > > System.NullReferenceException : Object reference not set to an > instance of an object. > at NHibernate.Type.Int32Type.Next(Object current, ISessionImplementor > session) in d:\CSharp\NH\nhibernate\src\NHibernate\Type\Int32Type.cs: > line 77 > at NHibernate.Engine.Versioning.Increment(Object version, IVersionType > versionType, ISessionImplementor session) in d:\CSharp\NH\nhibernate > \src\NHibernate\Engine\Versioning.cs: line 31 > at > NHibernate.Event.Default.DefaultFlushEntityEventListener.GetNextVersion(FlushEntityEvent > event) in d:\CSharp\NH\nhibernate\src\NHibernate\Event\Default > \DefaultFlushEntityEventListener.cs: line 331 > at > NHibernate.Event.Default.DefaultFlushEntityEventListener.ScheduleUpdate(FlushEntityEvent > event) in d:\CSharp\NH\nhibernate\src\NHibernate\Event\Default > \DefaultFlushEntityEventListener.cs: line 242 > at > NHibernate.Event.Default.DefaultFlushEntityEventListener.OnFlushEntity(FlushEntityEvent > event) in d:\CSharp\NH\nhibernate\src\NHibernate\Event\Default > \DefaultFlushEntityEventListener.cs: line 45 > at > NHibernate.Event.Default.AbstractFlushingEventListener.FlushEntities(FlushEvent > event) in d:\CSharp\NH\nhibernate\src\NHibernate\Event\Default > \AbstractFlushingEventListener.cs: line 161 > at > NHibernate.Event.Default.AbstractFlushingEventListener.FlushEverythingToExecutions(FlushEvent > event) in d:\CSharp\NH\nhibernate\src\NHibernate\Event\Default > \AbstractFlushingEventListener.cs: line 60 > at > NHibernate.Event.Default.DefaultDirtyCheckEventListener.OnDirtyCheck(DirtyCheckEvent > event) in d:\CSharp\NH\nhibernate\src\NHibernate\Event\Default > \DefaultDirtyCheckEventListener.cs: line 21 > at NHibernate.Impl.SessionImpl.IsDirty() in d:\CSharp\NH\nhibernate\src > \NHibernate\Impl\SessionImpl.cs: line 1510 > > The failures happened at "random" times, such as when I was about > to execute a query and NHibernate would do a dirty check. So I added > asserts for session.IsDirty() to try to catch the problem earlier, but > I still don't see an obvious cause. The odd thing is, the version > property should not be incrementing, since I am only doing read-only > work within the session so far. For example, the following code fails: > > > Assert.IsFalse(session.IsDirty()); > var query = session.CreateQuery("from " + typeof(T).Name); > var list = query.List<T>(); > Console.WriteLine(" HQL query: {0} " + typeof(T).Name + " > objects found", list.Count()); > Assert.AreEqual(_rowCount, list.Count()); // value cached > in test setup > Assert.IsFalse(session.IsDirty()); > > I have been looking at this all afternoon, and tried to recreate > the problem by pasting similar unit test code into the > NHibernate.Test.VersionTest unit tests. (No luck yet.) Also, I tried > doing a "session.Clear()" before running this code, (which I thought > might solve the problem if there was stale data in the session) but it > had no effect. > > I'm running out of ideas... does anyone have any thoughts on what > to look at next? > > Thanks, > Mike -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
