Web application design is an interesting topic. This book is not on web application design hence I will not spend too much time on it. But there is one aspect of web application design that is critical in deciding the scope of unit of work. Is your web application designed in such a way that every request performs a task that in itself can qualify as single business operation? Or in other words, does your web application handle any request that constitutes multiple business operations that can be finished independently of each other? If you do, then you are probably doing it wrong or you are making it difficult on yourself. Consider the following scenario.

You have a web application which takes some input from end user and then works on that input. Application performs two tasks, namely A and B, with those inputs. This is not clear to the user from the UI that they see but that is what happens behind the scenes. If both tasks A and B finish, then you take your users to a nice looking success page. But what if task A finishes but task B fails? Since your users do not know that there is task A and task B, you cannot tell them, "sorry folks, task B failed and you would need to provide the input again". Let's say you could do that; then what about task A that finished? If task A updated some database records (or inserted new ones), are you going to revert those operations? If you do not revert the operations, how would you ensure that next time the user provides the same input, you only perform task B because task A was finished already? Are you going to design your application as a state machine so that you remember where users left off last time?

You can see that there are too many questions and too many things to think about. I do not need to tell you that such a design would need lot of code to support it and even after that there would still be edge cases that would make your application fail over. So a decent and reliable design that you can implement with least amount of code is the one that wraps a single business operation in a web request. Such a design is also better from error recovery point of view. Now if you are going to code a single business operation per request, then we can safely say that if nothing goes wrong with processing of that request then the business operation can be called to have finished successfully. If there is any error during processing of the request then business operation fails. Any database changes made during a successful business operation should be committed at the end of the operation. The scope of unit of work needs to span across the whole business operation. In this design, a request wraps one business operation so we can say that scope of unit of work can span the whole request.

We know that ISession can act as unit of work. We have also established that a good design of web application extends the scope of unit of work to full request processing. So an instance of ISession for every incoming request, with its inherent unit of work capability, seems to fit nicely here. You open a new session at a point where incoming request first hits your code. At the same time, you begin a transaction. You use that session whenever you need to interact with database during processing of that request. The last point in your code before request leaves is where you decide whether you should commit the transaction and close the session or rollback the transaction and then close the session. Sounds like it can work. Rather, this is a pattern so famous that it is recognized by its own name "session per request" and NHibernate supports it natively through an implementation of contextual sessions which is what we learn next.

In order to implement "session per request" kind of pattern, we need an ability to hold on to a session as long as the request is being processed. In other words, the scope of session needs to be limited by lifetime of the request in whose context the session was created. Such sessions can be called contextual sessions. There are two mechanisms that let us have contextual sessions. One of the mechanisms is natively supported by NHibernate whereas the other mechanism is offered by most famous IoC containers. We will look at the native NHibernate offering in detail and leave the IoC container mechanism for our avid readers to explore on their own.

NHibernate's implementation of contextual sessions hinges around the following three operations:

The way this works is – when a new request comes in, you create a new session by calling the OpenSession method on session factory. You then tell NHibernate that a new context starts here and NHibernate stores the session object created. NHibernate has defined a class named NHibernate.Context.CurrentSessionContext. This class provides a method Bind which is used to signal NHibernate of beginning of context. From this point onwards, if you need this session object then you can call the GetCurrentSession method on session factory. After the request is processed, your context ends and you can call the Unbind method on CurrentSessionContext to tell NHibernate that the context has ended and it no longer needs to hold on to the session object.

It is possible that the previous text has left you even more confused and hence we will look at a code listing which should explain this in a better way. Following code listing shows implementation of a class SessionManager which we can use whenever we need access to current session object:

using NHibernate;
using NHibernate.Context;

namespace Persistence
{
  public class SessionManager
  {
    private static readonly ISessionFactory sessionFactory;

    static SessionManager()
    {
      sessionFactory = new DatabaseConfiguration()
                      .BuildSessionFactory();
    }

    public static ISession GetCurrentSession()
    {
      if (CurrentSessionContext.HasBind(sessionFactory))
      {
        return sessionFactory.GetCurrentSession();
      }

      var session = sessionFactory.OpenSession();
      CurrentSessionContext.Bind(session);
      return session;
    }

    public static void Unbind()
    {
      CurrentSessionContext.Unbind(sessionFactory);
    }
  }
}

First and the most important thing about the preceding code is that the GetCurrentSession method is made static so that it can be called from anywhere. There is no need to instantiate the SessionManager class in order to get instance of session. We would look at code inside the GetCurrentSession method line by line. Before that, note that there is a static constructor where session factory is built.

The first line in GetCurrentSession is an if condition which calls CurrentSessionContext.HasBind and passes the session factory to it. We are seeing this method for the first time. This method returns true if an existing session has been tracked by the context already. In that case, we just call sessionFactory.GetCurrentSession() to return that tracked session. If no session is tracked, then we open a new session by calling sessionFactory.OpenSession(). The next line passes this newly created session to the CurrentSessionContext.Bind method to tell the session context that it should track this session.

So first call to SessionManager.GetCurrentSession will open a new session, add it to context, and return it. Subsequent calls to this method would return the same session object.

When processing of the request finishes, you can tell NHibernate to forget about the session object by calling the SessionManager.Unbind method. This method internally calls the CurrentSessionContext.Unbind method which takes session factory as input.

This looks good so far. But the following two questions are still unanswered:

Answer to the first question lies in the implementation of CurrentSessionContext. There are more than one implementations of CurrentSessionContext. You can configure which one you want to use for you application. We would discuss this next. Second question is more of an ASP.NET MVC detail and has nothing to do with NHibernate. After we discuss the configuration of CurrentSessionContext, we would turn our attention to this aspect.

Implementation of CurrentSessionContext is pluggable. What that means is that you can inherit from this class and have your own implementation of contextual sessions. You can then choose to have storage of contextual sessions managed in a better and thread-safe way so that no two web requests get hold of the same session object. The good news is that NHibernate provides an implementation which does exactly that. NHibernate implements a class WebSessionContext which uses HttpContext to store the session. This stored instance of session is available to use throughout the processing of the request. During NHibernate configuration you can declare that you want to use WebSessionContext as your current session context class. Following code shows how to do this:

public class DatabaseConfiguration : Configuration
{
  public DatabaseConfiguration()
  {
    this.CurrentSessionContext<WebSessionContext>();
  }
}

Note that there is other NHibernate configuration in the preceding class which is not shown here in order to save space. If you remember from Chapter 4, NHibernate Warmup, programmatic configuration of NHibernate is done using the NHibernate.Cfg.Configuration class. You can instantiate this class directly. Here I have preferred to inherit from that class and declared the entire configuration inside the inherited class. The Configuration class exposes a method CurrentSessionContext<T>. This method is used to tell NHibernate which implementation of contextual session we want to use. Since our application is a web application, we have used WebSessionContext here but the following different implementations are available to use in different situations. Remember that all these implementations do the exact same thing – track session by storing them somewhere. Where they differ is the storage mechanism that is used which makes them suitable to be used in different kind of applications/setups.

If the previous OOTB implementations do not help with your situation then you can always implement your own. But I am yet to come across a situation where this is needed. Now let's look into implementing session per request using contextual sessions.

To implement "session per request" pattern, you need to be able to create a new session when a new request comes in, then use that session throughout the request processing and in the end, dispose the session. .NET provides hooks that you can use to intercept requests when they come in and leave. All web/service frameworks of .NET provide such hooks. The idea is to use these hooks to create a new session when a new request comes in and dispose the session when the request processing is done. Let's quickly run through different options available for hooking into request pipeline to implement "session per request".

public class DatabaseSessionModule : IHttpModule
{
  public void Init(HttpApplication context)
  {
    context.BeginRequest += Context_BeginRequest;
    context.EndRequest += Context_EndRequest;
  }

  private void Context_EndRequest(object sender, System.EventArgs e)
  {
var session = SessionManager.GetCurrentSession();
session.Close();
session.Dispose();
  }

  private void Context_BeginRequest(object sender, System.EventArgs e)
  {
var session = SessionManager.GetCurrentSession();
  }

  public void Dispose()
  {

  }
}

public class MvcApplication : HttpApplication
{
  protected void Application_Start()
  {
    //Other MVC specific code
  }

  protected void Application_BeginRequest(object sender, EventArgs e)
  {
    var session = SessionManager.GetCurrentSession();
  }

  protected void Application_EndRequest(object sender, EventArgs e)
  {
    var session = SessionManager.GetCurrentSession();
    session.Close();
    session.Dispose();
  }
}

public class RequiresDatabaseSession : ActionFilterAttribute
{
  public override void OnActionExecuting(ActionExecutingContext filterContext)
  {
    var session = SessionManager.GetCurrentSession();
  }

  public override void OnActionExecuted(ActionExecutedContext filterContext)
  {
    var session = SessionManager.GetCurrentSession();
    session.Close();
    session.Dispose();
  }
}

public interface IDispatchMessageInspector
{
  public object AfterReceiveRequest(
  ref System.ServiceModel.Channels.Message request,
  IClientChannel channel, InstanceContext instanceContext;

public void BeforeSendReply(
  ref System.ServiceModel.Channels.Message reply,
  object correlationState;

}

We have talked about unit of work in quite some detail so far. You probably have a very clear picture of what unit of work does. In this section, we would quickly look at couple of different ways of implementing unit of work.

public override void OnActionExecuting(ActionExecutingContext filterContext)
{
  var session = SessionManager.GetCurrentSession();
  session.BeginTransaction();
}

public override void OnActionExecuted(ActionExecutedContext filterContext)
{
  var session = SessionManager.GetCurrentSession();
  var transaction = session.Transaction;

  if (transaction.IsActive)
  {
    if (filterContext.Exception != null)
    {
      transaction.Rollback();
    }
    else
    {
      transaction.Commit();
    }
  }
  session.Close();
  session.Dispose();
}

public class UnitOfWork
{
  private readonly ITransaction transaction;

  public UnitOfWork(ISession session)
  {
    transaction = session.BeginTransaction();
  }

  public void Commit()
  {
    if(transaction.IsActive) transaction.Commit();
  }

  public void Rollback()
  {
    if(transaction.IsActive) transaction.Rollback();
  }
}