IntroductionNHibernate session is a gateway for all operations that you perform on your datastore. It also plays a role of the first-level cache, minimizing the number of roundtrips between your application and the database server. As NHibernate documentation states, session is "a single-threaded, short-lived object representing a conversation between the application and the persistent store". Pay special attention to the bolded words: single-threaded and short-lived. Single-threaded in web-development world basically means that you should not use the same session instance in two or more concurrent requests. Short-lived on the other hand instructs you not to "overuse" the session instance so it does not become a copy of the database. It's on the developer's shoulders to meet those requirements and implement a correct session management. Fortunately, there are several patterns already created for this purpose: session-per-request, session-per-conversation, session-per-thread, etc. with their implementation exemplars easily accessible in the Internet. But even if you take one of those examples and adapt it to your application needs, it may happen that the session does not behave in a way that you would expect: objects are not persisted, events are not fired or you get LazyLoadException. Those nasty bugs are usually quite tricky to resolve, especially in enterprise-level applications where objects lifetime is controlled by some kind of Inversion of Control container. In this article, I would like to show you how to find the exact moments when the session is created and destroyed (and by whom) and what information can be retrieved from its properties. The usual approach in investigating NHibernate internals would be to turn on its fine-grained logging and check the log4net appenders output. However it's not the approach that I would like to describe in this post (please make a comment if you wish to read an article about detailed NHibernate logging). Today, we will focus on how to use the Visual Studio debugger to examine the session management. I prepared a sample application on which you may train the debugging process (details of the configuration are provided at the end of the post).
Prepare NHibernate SymbolsTo be able to debug the NHibernate source code, the debugger must know how to find it. If you are using the 3.0.0 version of NHibernate, you may use http://www.symbolsource.org configuring Visual Studio to use their symbol store. If your NHibernate version is different, you need to either compile NHibernate on your own and reference the produced binaries in your project or make use of the sourcepack script. Here I will describe the second approach (especially because I'm the author of the sourcepack and I need to advertise it somehow ;)). To use sourcepack, you will need to install Debugging Tools for Windows (you may install them from the WDK image) and powershell v2. The next step is to download NHibernate binaries (you should have them already in your application bin folder) and NHibernate sources from their sourceforge page.
Read more: Codeproject
QR:
Prepare NHibernate SymbolsTo be able to debug the NHibernate source code, the debugger must know how to find it. If you are using the 3.0.0 version of NHibernate, you may use http://www.symbolsource.org configuring Visual Studio to use their symbol store. If your NHibernate version is different, you need to either compile NHibernate on your own and reference the produced binaries in your project or make use of the sourcepack script. Here I will describe the second approach (especially because I'm the author of the sourcepack and I need to advertise it somehow ;)). To use sourcepack, you will need to install Debugging Tools for Windows (you may install them from the WDK image) and powershell v2. The next step is to download NHibernate binaries (you should have them already in your application bin folder) and NHibernate sources from their sourceforge page.
Read more: Codeproject
QR: