What's the simplest way to preserve a NHibernate ISessionFactory for web pages and web services?

Question

What's the simplest way to preserve a NHibernate ISessionFactory for web pages and web services?

I'll get into the Rhino Commons and Windsor this and that later. I'm looking for the basic concept.

Is this correct?

I've been trying to find guidance on how to deal with the ISessionFactory as simply as possible. I'm also looking for a solution that would work in both web pages and web services. The examples that I've seen deal with web pages and never touch the subject of web services. They start by building a Httpmodule that creates the ISessionFactory and store it in a static variable (e.g., Jeffery Palermo's HybridSessionBuilder (jeffreypalermo.com/blog/use-this-nhibernate-wrapper-to-keep-your-repository-classes-simple/) or in the Summer of NHibernate's (www.summerofnhibernate.com see StaticSessionManager in Session 13). I've also noticed that despite the fact that ISessionFactory implements IDisposable nobody seems to be disposing of it. I guess they just let the garbage collector dispose of it when the web application ends, which would occur if IIS is recycled or the web site becomes idle.

If all this is true, the simplest thing would be to create some class that has a static variable that is used to store the ISessionFactory. This class would be instantiated and used by web pages and web services. Each time the class is instantiated, I would check to make sure that the static ISessionFactory variable is not null. If it is null, I recreate it. Thus, I keep the ISessionFactory alive by having something, either a web page or web service, within the web application create an instance of the class. The fact that the ISessionFactory is in a static variable means that it is shared by every instance of the class. Since the session factory is thread safe, this is ok. As long as I don't share ISessions, I'm golden. When nobody has an instance of this common class, the static variable is no longer referenced and garbage collection will destroy of the ISessionFactory .

Is this the basic principle behind keeping the ISessionFactory alive?

Answer 1

I think you have it mostly figured out.

The reason no one is disposing of the session factory is that, in general, you really don't want to. Building the session factory is an extremely expensive operation that can take many seconds, so you want to hold onto it for as long as possible. The .NET runtime will actually create a pool of HttpApplications and may create/dispose of them at will. So if you can store the session factory outside of the application, at the AppDomain scope, that is preferable since the factory will endure until the domain is recycled. Declaring the session factory as static will achieve this so that's why that is done; see the MSDN docs on static classes:

A static constructor is only called one time, and a static class remains in memory for the lifetime of the application domain in which your program resides.

So, if you make the session factory container static and never explicitly dispose of it, it will remain in memory until the AppDomain is recycled, maximizing the utility of that factory instance and the performance of your application.