I have been doing some optimisation of queries done by NHibernate HQL. To optimise I have rewritten some of them to use the HQL IN expression.

Point: important to check the collection parameter, if NULL or Empty, NHibernate criteria will fail.

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

Using the “Stack Trace” in NHprof I identified a call being made to GetHashCode() of the class (MyClass) holding the composite id. MyClass looked like this:

public class MyClass
{
    public virtual Key1Class Key1 { get; set; }
    public virtual Key2Class Key2 { get; set; }

    /*
     * Other virtual properties
     * ...
     */

    public override int GetHashCode()
    {
        unchecked
        {
            return ((Key1 != null ? Key1.GetHashCode() : 0) * 397) ^ (Key2 != null ? Key2.GetHashCode() : 0);
        }
    }
}

Note that Key1 and Key2 are both references, and please take a closer look at the GetHashCode method.

The problem

The problem I was facing… NHibernate called the GetHashCode() of MyClass when doing the query. And the call to MyClass‘s GetHashCode method subsequentily called GetHashCode() of both the Key1 and Key2 classes.

Key1 and Key2 were loaded as proxies and hence a call to something else than theirs Id resulted in a select being fired.

The solution

The solution was to rewrite the GetHashCode method to this:

public override int GetHashCode()
{
    unchecked
    {
        return ((Key1 != null ? Key1.Id : 0) * 397) ^ (Key2 != null ? Key2.Id : 0);
    }
}

Note that both Id’s of KeyClass1 and KeyClass2 are integers.

Now a call to MyClass GetHashCode does not result in individual SELECT statements being fired, even though the Keys area lazy loaded.

With the new provider model introduced in ASP.NET 4, it is now possible to write providers for output caching and session state. Enyim has done just that with their memcache-provider.

I use NHibernate for some of my projects and being able to use a Membase cache provider for NHibernates second level cache would be very nice.

With help from Christian Dalager and my self, such a library is now available. Take a look here https://bitbucket.org/ovesen/membasecacheprovider

Zipped binaries are provided with mapping against NHibernate 2.0.1, 2.1.0, 2.1.2 and NH3 here https://bitbucket.org/ovesen/membasecacheprovider/downloads

An example configuration file is provided in the downloads, but else you can see the options here:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <!-- This is a sample configuration file for using MembaseCacheProvider -->

    <configSections>

        <!-- (Required) Default configuration section for Membase -->
        <section name="membase" type="Membase.Configuration.MembaseClientSection, Membase" />

        <!-- (Optional) An additional configuration section for Membase, can be used to target another bucket or servers -->
        <section name="membaseNhibernate" type="Membase.Configuration.MembaseClientSection, Membase" />

        <!-- (Optional) A section for the Enyim Membase client, allows loggint to e.g. log4net -->
        <sectionGroup name="enyim.com">
            <section name="log" type="Enyim.Caching.Configuration.LoggerSection, Enyim.Caching" />
        </sectionGroup>

        <!-- (Optional, but recommended) A configuration section that allows specific settings to be set for different NHibernate caching regions -->
        <section name="membaseNhibernateCache" type="MembaseCacheProvider.MembaseNhConfiguration, MembaseCacheProvider" />

    </configSections>

    <!-- (Optional) Defines that log4net should be used for Membase client logging, remember to define log4net configuration -->
    <enyim.com>
        <log factory="Enyim.Caching.Log4NetFactory, Enyim.Caching.Log4NetAdapter" />
    </enyim.com>

    <!-- (Required) Maps to the configuration section named "membase", defines a single server url and the "default" bucket -->
    <!-- Other configuration settings are available, look in the Enyim documentation and examples -->
    <!-- here http://memcached.enyim.com/ or here https://github.com/enyim/memcached-providers -->
    <membase>
        <servers bucket="default">
            <add uri="http://localhost:8091/pools/default" />
        </servers>
    </membase>

    <!-- (Optional) Maps to the configuration section name "membaseNhibernate", defines a single server url and the bucket "default_nhibernate" -->
    <membaseNhibernate>
        <servers bucket="default_nhibernate">
            <add uri="http://localhost:8091/pools/default" />
        </servers>

        <!-- (Optional) Sets specific settings for the socket pool -->
        <socketPool minPoolSize="10" maxPoolSize="100" connectionTimeout="00:00:10" />

        <!-- (Optional) Sets a specific locator -->
        <locator type="Enyim.Caching.Memcached.DefaultNodeLocator, Enyim.Caching" />
    </membaseNhibernate>

    <!-- (Optional, but recommended) Configuration settings of NHibernate second level cache, Membase provider -->
    <!-- The section attribute defines that the Membase configuration names "membaseNhibernate" should be used -->
    <membaseNhibernateCache section="membaseNhibernate">

        <!-- Here expiration details are specified for the Nhibernate cache regions LongTerm and ShortTerm -->
        <!-- The expiration are defined in minutes, meaning LongTerm = 60 minutes and ShortTerm = 2 minutes -->
        <cache region="LongTerm" expiration="60" />
        <cache region="ShortTerm" expiration="2" />
    </membaseNhibernateCache>

</configuration>

Reference:
http://west-wind.com/weblog/posts/132081.aspx

I have been using NHibernate for some time now, and I am very satisfied with the functionality it provides. However, I do really not like “magic strings” as these makes the code resistent to refactoring.

NHibernate makes use of “magic strings” when doing a query using HQL or the Criteria API. I tend to use the Criteria API as this, opposed to HQL, limits the logic encompassed in “magic strings”.

As I mostly use the Criteria API, I thought, why not do something about it  So I did. Very quickly a Fluent Criteria interface was implemented. Here is how it is used:

var email = "email@email.com";
var customerType = CustomerType.Default;

var result = nhSession.Criteria<Customer>()
             .Add.Equals(x => x.Email, email)
             .Add.Equals(x => x.Type, customerType)
             .Order.Desc(x => x.Created)
             .NHCriteria
                 .SetMaxResults(1)
                 .UniqueResult<Customer>();

In this line we call the extension method Criteria with Customer as a generic argument:

var result = nhSession.Criteria<Customer>()

By doing so we of the alternate Fluent Criteria API I have implemented. Currently it is only some of the Restrictions and Order classes that have been implemented, but you are free to use these classes and extend them as you wish.

By calling the NHCriteria property, you get the normal NHibernate criteria API, so here you can set the cache options, max results, etc.

Download the source code here http://ovesen.codeplex.com/wikipage?title=NHibernateFluentCriteria&referringTitle=Home

Happy New Year btw

I have been using Castle Windsor and NHibernate for some months now, so I am a bit new and still learning. But then again, it is learning developers like me, that asks all the questions.

This post is also written because of a simple question: Does the HybridSessionBuilder support multiple configurations?

Why this question? Well, I have a project where some repositories uses one database and some other uses another database.

Original implementation

My little journey started out with my looking original implementation of the HybridSessionBuilder (HSB). You can read about the original implementation here:

http://jeffreypalermo.com/blog/use-this-nhibernate-wrapper-to-keep-your-repository-classes-simple/

But as you can see:

The original implementation used a static session factory and session, so this is does not support multiple configurations.

CodeCampServer/Tarantino

I then found out that the CodeCampServer also was using the HSB. Hoping to find an implementation that supported my request, I then started to read the source code.

But by viewing the source code for CodeCampServer I soon found out that the code, for the HSB, had been updated to support multiple factories and sessions. Yeeeaaaaa

Furthermore I found out that the HSB now is a part of a collection of libraries called Tarantino.

I was happy, the HybridSessionBuilder now supported my requests, and it was ready to be used in my projects. I thought.

Test web application

Then I build a small test web application project. It used Castle Windsor (for dependency injection) and NHibernate. I quickly configured Castle Windsor and made two NHibernate configuration files.

nhibernate.cfg.xml used this connection string:

Data Source=localhost\sqlexpress;Initial Catalog=DB1;Integrated Security=true

nhibernate2.cfg.xml used this connection string:

Data Source=localhost\sqlexpress;Initial Catalog=DB2;Integrated Security=true

My windsor.config.xml looks like this:

<component id="firstRepository" type="HybridSessionBuilderTest.FirstRepository, HybridSessionBuilderTest">

  <parameters>

    <ConfigurationFile>hibernate.cfg.xml</ConfigurationFile>

  </parameters>

</component>

<component id="secondRepository" type="HybridSessionBuilderTest.SecondRepository, HybridSessionBuilderTest">

  <parameters>

    <ConfigurationFile>hibernate2.cfg.xml</ConfigurationFile>

  </parameters>

</component>

It basically just configures the two repositories with each own configuration.

But to my surprise, it did not work. I made a small page that prints the connection string of each of the repositories:

Only the default NHibernate configuration file was used.

Bug or feature?

That was not the output I was looking for, so to find the problem, I did some more test and dug into the code.

I was expecting an object structure like this:

But I got something like this:

  I identified the following method to be the central, when the session was instantiated:

   1: private ISession getExistingOrNewSession(ISessionFactory factory, string configurationFile)

   2:         {

   3:             if (HttpContext.Current != null)

   4:             {

   5:                 var session = GetExistingWebSession();

   6:  

   7:                 if (session == null || !session.IsOpen)

   8:                 {

   9:                     session = openSessionAndAddToContext(factory, configurationFile);

  10:                 }

  11:  

  12:                 return session;

  13:             }

  14:  

  15:             var currentSession = _currentSessions.ContainsKey(configurationFile)

  16:                                     ? _currentSessions[configurationFile]

  17:                                     : null;

  18:             if (currentSession == null || !currentSession.IsOpen)

  19:             {

  20:                 _currentSessions[configurationFile] = OpenSession(factory);

  21:             }

  22:  

  23:             return _currentSessions[configurationFile];

  24:         }

Patch/solution

The problem I identified is line #5. It returns the existing session based on the default configuration, no matter what you specify in the configurationFile parameter.

I changed it to:

   1: var session = GetExistingWebSession(configurationFile);

And tadaaa:

The second repository now uses the second configuration file

Conclusion

You might ask, why I spend time writing a blog post describing this little change to the HybridSessionBuilder.

First of all, having a HSB that can use multiple configurations is rather important to me and the projects I am working on.

Second of all, as NHibernate and Castle Windsor is still a bit new to me, one of the best ways to learn its capabilities and how to use it, is to dig in deep. And that is exactly what I have done.

And BTW – I have not just learned about HSB, but also CodeCampServer, Tarantino, S#arp and how it handles multiple configurations, and how it all works together.

NHibernateSessionModule

Please note. Before my change is used, you need to also update the NHibernateSessionModule. It does currently not dispose all the sessions that are opened.

I have been using Castle Windsor and NHibernate for some months now, so I am a bit new and still learning. But then again, it is learning developers like me, that asks all the questions.

This post is also written because of a simple question: Does the HybridSessionBuilder support multiple configurations?

Why this question? Well, I have a project where some repositories uses one database and some other uses another database.

Original implementation

My little journey started out with my looking original implementation of the HybridSessionBuilder (HSB). You can read about the original implementation here:

http://jeffreypalermo.com/blog/use-this-nhibernate-wrapper-to-keep-your-repository-classes-simple/

But as you can see:

The original implementation used a static session factory and session, so this is does not support multiple configurations.

CodeCampServer/Tarantino

I then found out that the CodeCampServer also was using the HSB. Hoping to find an implementation that supported my request, I then started to read the source code.

But by viewing the source code for CodeCampServer I soon found out that the code, for the HSB, had been updated to support multiple factories and sessions. Yeeeaaaaa

Furthermore I found out that the HSB now is a part of a collection of libraries called Tarantino.

I was happy, the HybridSessionBuilder now supported my requests, and it was ready to be used in my projects. I thought.

Test web application

Then I build a small test web application project. It used Castle Windsor (for dependency injection) and NHibernate. I quickly configured Castle Windsor and made two NHibernate configuration files.

nhibernate.cfg.xml used this connection string:

Data Source=localhost\sqlexpress;Initial Catalog=DB1;Integrated Security=true

nhibernate2.cfg.xml used this connection string:

Data Source=localhost\sqlexpress;Initial Catalog=DB2;Integrated Security=true

My windsor.config.xml looks like this:

<component id="firstRepository" type="HybridSessionBuilderTest.FirstRepository, HybridSessionBuilderTest">

  <parameters>

    <ConfigurationFile>hibernate.cfg.xml</ConfigurationFile>

  </parameters>

</component>

 

<component id="secondRepository" type="HybridSessionBuilderTest.SecondRepository, HybridSessionBuilderTest">

  <parameters>

    <ConfigurationFile>hibernate2.cfg.xml</ConfigurationFile>

  </parameters>

</component>

 

It basically just configures the two repositories with each own configuration.

But to my surprise, it did not work. I made a small page that prints the connection string of each of the repositories:

Only the default NHibernate configuration file was used.

Bug or feature?

That was not the output I was looking for, so to find the problem, I did some more test and dug into the code.

I was expecting an object structure like this:

But I got something like this:

  I identified the following method to be the central, when the session was instantiated:

   1: private ISession getExistingOrNewSession(ISessionFactory factory, string configurationFile)

   2:         {

   3:             if (HttpContext.Current != null)

   4:             {

   5:                 var session = GetExistingWebSession();

   6: 

   7:                 if (session == null || !session.IsOpen)

   8:                 {

   9:                     session = openSessionAndAddToContext(factory, configurationFile);

  10:                 }

  11: 

  12:                 return session;

  13:             }

  14: 

  15:             var currentSession = _currentSessions.ContainsKey(configurationFile)

  16:                                     ? _currentSessions[configurationFile]

  17:                                     : null;

  18:             if (currentSession == null || !currentSession.IsOpen)

  19:             {

  20:                 _currentSessions[configurationFile] = OpenSession(factory);

  21:             }

  22: 

  23:             return _currentSessions[configurationFile];

  24:         }

Patch/solution

The problem I identified is line #5. It returns the existing session based on the default configuration, no matter what you specify in the configurationFile parameter.

I changed it to:

   1: var session = GetExistingWebSession(configurationFile);

 

And tadaaa:

The second repository now uses the second configuration file

Conclusion

You might ask, why I spend time writing a blog post describing this little change to the HybridSessionBuilder.

First of all, having a HSB that can use multiple configurations is rather important to me and the projects I am working on.

Second of all, as NHibernate and Castle Windsor is still a bit new to me, one of the best ways to learn its capabilities and how to use it, is to dig in deep. And that is exactly what I have done.

And BTW – I have not just learned about HSB, but also CodeCampServer, Tarantino, S#arp and how it handles multiple configurations, and how it all works together.

I have been using Castle Windsor and NHibernate for some months now, so I am a bit new and still learning. But then again, it is learning developers like me, that asks all the questions.

This post is also written because of a simple question: Does the HybridSessionBuilder support multiple configurations?

Why this question? Well, I have a project where some repositories uses one database and some other uses another database.

Original implementation

My little journey started out with my looking original implementation of the HybridSessionBuilder (HSB). You can read about the original implementation here:

http://jeffreypalermo.com/blog/use-this-nhibernate-wrapper-to-keep-your-repository-classes-simple/

But as you can see:

The original implementation used a static session factory and session, so this is does not support multiple configurations.

CodeCampServer/Tarantino

I then found out that the CodeCampServer also was using the HSB. Hoping to find an implementation that supported my request, I then started to read the source code.

But by viewing the source code for CodeCampServer I soon found out that the code, for the HSB, had been updated to support multiple factories and sessions. Yeeeaaaaa

Furthermore I found out that the HSB now is a part of a collection of libraries called Tarantino.

I was happy, the HybridSessionBuilder now supported my requests, and it was ready to be used in my projects. I thought.

Test web application

Then I build a small test web application project. It used Castle Windsor (for dependency injection) and NHibernate. I quickly configured Castle Windsor and made two NHibernate configuration files.

nhibernate.cfg.xml used this connection string:

Data Source=localhost\sqlexpress;Initial Catalog=DB1;Integrated Security=true

nhibernate2.cfg.xml used this connection string:

Data Source=localhost\sqlexpress;Initial Catalog=DB2;Integrated Security=true

My windsor.config.xml looks like this:

<component id="firstRepository" type="HybridSessionBuilderTest.FirstRepository, HybridSessionBuilderTest">

  <parameters>

    <ConfigurationFile>hibernate.cfg.xml</ConfigurationFile>

  </parameters>

</component>

<component id="secondRepository" type="HybridSessionBuilderTest.SecondRepository, HybridSessionBuilderTest">

  <parameters>

    <ConfigurationFile>hibernate2.cfg.xml</ConfigurationFile>

  </parameters>

</component>

It basically just configures the two repositories with each own configuration.

But to my surprise, it did not work. I made a small page that prints the connection string of each of the repositories:

Only the default NHibernate configuration file was used.

Bug or feature?

That was not the output I was looking for, so to find the problem, I did some more test and dug into the code.

I was expecting an object structure like this:

But I got something like this:

  I identified the following method to be the central, when the session was instantiated:

   1: private ISession getExistingOrNewSession(ISessionFactory factory, string configurationFile)

   2:         {

   3:             if (HttpContext.Current != null)

   4:             {

   5:                 var session = GetExistingWebSession();

   6:  

   7:                 if (session == null || !session.IsOpen)

   8:                 {

   9:                     session = openSessionAndAddToContext(factory, configurationFile);

  10:                 }

  11:  

  12:                 return session;

  13:             }

  14:  

  15:             var currentSession = _currentSessions.ContainsKey(configurationFile)

  16:                                     ? _currentSessions[configurationFile]

  17:                                     : null;

  18:             if (currentSession == null || !currentSession.IsOpen)

  19:             {

  20:                 _currentSessions[configurationFile] = OpenSession(factory);

  21:             }

  22:  

  23:             return _currentSessions[configurationFile];

  24:         }

Patch/solution

The problem I identified is line #5. It returns the existing session based on the default configuration, no matter what you specify in the configurationFile parameter.

I changed it to:

   1: var session = GetExistingWebSession(configurationFile);

And tadaaa:

The second repository now uses the second configuration file

Conclusion

You might ask, why I spend time writing a blog post describing this little change to the HybridSessionBuilder.

First of all, having a HSB that can use multiple configurations is rather important to me and the projects I am working on.

Second of all, as NHibernate and Castle Windsor is still a bit new to me, one of the best ways to learn its capabilities and how to use it, is to dig in deep. And that is exactly what I have done.

And BTW – I have not just learned about HSB, but also CodeCampServer, Tarantino, S#arp and how it handles multiple configurations, and how it all works together.

The configuration sis done in Fluent NHibernate.

http://codebetter.com/blogs/kyle.baley/archive/2008/12/24/many-to-many-relationships-with-data-attached-in-nhibernate.aspx