We have recently update to NHibernate 3 in one of our projects. While testing I was suddenly seeing some weird UPDATE statements in NHprof.

It seemed like the NHibernate IsDirty detection had changed.

After some digging it turned out that our mapping files (made in FluentNhibernate) actually contained some minor errors when compared to the DB schema. Minor errors like value typed properties not being nullable when the ClassMap said it should be.

Debugging of NHibernate projects

I found that inserting the following into the classmaps made debugging a lot easier:

DynamicUpdate();

Now only the properties that are Dirty (according to NHibernate) are used in the SQL UPDATE statement. Here are the description from NHibernate docs:

• dynamic-update (optional, defaults to false): Specifies that UPDATE SQL should be generated at runtime and contain only those columns whose values have changed.
• dynamic-insert: (optional, defaults to false): Specifies that INSERT SQL should be generated at runtime and contain only the columns whose values are not null.

That led me directly to the property in the mapping files that had errors in it, and I could easily fix it.

Conclusion

So, in our case, it wasn’t really the NHibernate dirty detection that changed, NHibernate 3 is just not as fault tolerant, than that of NH2. So the upgrade made us discover some errors that should be corrected.

As such, this is a good thing, but it would have been nicer if NH2 had made us aware of these errors in the first place.

But hey, better late than never

I struggled with Membase last night. I added NHibernate 2. level caching, Asp.net Session caching, Output caching and custom caching to some new Membase providers.

It worked at first, but then suddenly nothing was cached, and nothing was retrieved from the cache. I was working on my development machine and it seems like the problem is due to the network switching.

Well here is how it was solved. First navigate to the Membase server directory (C:\Program Files\Membase\Server\bin). Then execute the following commands.

service_stop.bat
service_unregister.bat
service_register.bat ns_1@127.0.0.1
service_start.bat

Read the original here: http://blog.danhulton.com/2011/02/05/membase-on-windows-7-ip-address-fix/

The problem

When I inserted some breakpoints in my code, the first one was almost all the time hit. However, when I tried to step through the code, it worked fine for a bout 3-6 steps. But then Visual Studio debugger decided that was enough, and just completed the code.

The good thing was, it forced me to write many unit test cases, but sometimes I really think it is nice to visually see the state of your objects, in the code.

I have spoken to colleagues, and tested with different combinations of Gallio, Testdriven.NET and Re-sharper enabled, as I thought they cased the problem. But the debugger just kept bugging me. I had actually given up finding a solution to this problem, thinking that Visual Studio 2010 would fix it.

The solution

So finally, in a complete other context, I stumbled upon this page:

http://code.msdn.microsoft.com/KB957912

And thought…. that title sounds interesting… I quickly moved to the KB article, and started to read. I thought, that sounds exactly as my problem.

With nothing to loose I installed the update, and started to test the debugger… until now it seems to work

- please note, I do not use the debugger that often as I write very reliable code

Debugging OutOfMemoryExceptions in managed code using Windbg

http://blogs.msdn.com/amolravande/archive/2008/12/16/debugging-outofmemoryexceptions-in-managed-code-using-windbg.aspx

Query Data with Parallel LINQ

http://blogs.msdn.com/charlie/archive/2008/12/15/query-data-with-parallel-linq.aspx

—

In this video we learn how to use Visual Studio 2005 to debug ASP.NET AJAX applications. We are shown how the ScriptManager is used to access the JavaScript created by the ASP.NET AJAX server controls, and we also see how to use the Sys.Debug class to insert a trace message and a breakpoint.

View video: WinVideo-ASP-DebugAJAXApplicationsUsingVisualStudio2005.wmv (16.89 mb)