Application Performance: Open Session In View Design Pattern

Jonathon Gottschalk — 02/22/2010

I have been developing applications for the web for over 10 years, and I now primarily focus my efforts on the server-side of application development using.NET. Furthermore, I find myself devoting a considerable amount of effort towards making a sound architecture that can not only scale, but perform adequately under heavy load. This need has resulted in much research towards optimizing database transactions, connections, and queries.

As a developer my interest in design patterns has also been quite involved, and the Open Session In View Design Pattern is one of those patterns whose implementation has always fascinated me as a truly innovative solution to an otherwise seeming complex problem. This design pattern requires a solid understanding of database connections, transactions, and the MVC (Model-View-Controller) design pattern.

Background

First, let’s dissect the name of this design pattern to better understand where it originates. The “View” in the name of the pattern refers to the V in MVC. The View is the part of the MVC design pattern that renders output to the client’s machine. A web application designed with an MVC design pattern would render HTML into its View for the client’s browser to then display on their screen.

Next, we need to analyze the “Open Session” part of the name. This part of the name reflects the abstract nature of this design pattern. The database connection and transaction combine to form a database “session.” Thus, when a user wants to render the web page the application must initiate a “session” with the database to perform its work.

Also, you may wonder who even came up with this concept. I don’t claim to be a historian, but my knowledge of this design pattern comes from the creators of Hibernate in the Java world. My personal exposure to it has been with NHibernate (the .NET port of the popular ORM library), and you can read more about it here: https://www.hibernate.org/43.html.

Explanation

The basic concept of this design pattern is simple: when a user connects to the web server, the web application starts running code which creates the HTML they will eventually see (the View). When this user first connects, this causes a session to begin with the database, which opens a connection and starts a transaction. Then, the web application continues running through all of the necessary code to create the page and once it finishes, it commits the transaction and closes the database connection, which ends the session. All of the code that runs during the rendering of the HTML uses the same database connection and transaction. This means that every user who connects to the web server that causes application code to run will only ever initiate a single connection to the back-end database.

Advantages

This design pattern has advantages and disadvantages just like any other architectural decision you will make for your application. The advantages I can associate with this design pattern include, but are not limited to, the following:

Promotes Maintainability
I am a fan of short clean code, and this design pattern certainly emphasizes it. If you implement this design pattern in your application, you will quickly realize that a single entry point for retrieving your database connection and transaction certainly makes things a lot cleaner. It promotes the maintainability of your code by making that single point of entry the only area of interest if future updates to the application become necessary, which by proxy promotes the concept of refactoring.
Increases Performance
If your application is opening database connections and transactions all over the place during the normal execution of the view, you are most definitely going to see a performance gain by using this pattern. One of the largest overhead penalties that your application can incur is the creation and destruction of database connections. This design pattern isolates it down to a single connection and transaction, thus eliminating the overhead normally associated with creating and destroying the connection.
Easy to Understand
The design pattern, unlike some more abstract ones I have been exposed to, is far easier to comprehend because you can actually describe it both visually and verbally to another developer who is not familiar with it. I know this may seem like a rather insignificant selling point for this design pattern, but I am always one to promote simple to understand code that I will have to explain and teach to junior developers.
Database and Programming Language Neutral
The design pattern is not specific to .NET – you can just as easily demonstrate its implementation in PHP, Classic ASP, Java, and almost any other language. In fact, it is not even web-specific – the design pattern can be adapted to an application context just as easily as it can be adapted to a web context. Furthermore, it is also not database specific – you could utilize this design pattern with any database imaginable (MySQL, Oracle, SQL Server, Access, etc) with the same result.
Does not truly rely on MVC
Although the background of this design pattern is based on the View part of the MVC design pattern, you can usually find a way to retrofit existing applications with this design pattern. It provides a viable option when examining performance problems with legacy applications.
Reduces Concurrency Issues
This design pattern also helps reduce concurrency issues by maintaining a single transaction the whole time the view is rendered. This means that changes to the database by other threads should not affect the output, unless you are doing something very custom with your isolation levels. For more information about the impact of isolation levels and their impact in a multi-user environment, take a look at this article: http://sqlblogcasts.com/blogs/tonyrogerson/archive/2006/11/16/1345.aspx.

Disadvantages

This design pattern, despite many of its seeming advantages, also has drawbacks. I will try to enumerate through some of the ones I have encountered when utilizing it below:

Performance gains can hide chatty apps
A competent DBA will tell you they don’t want chatty apps that continually pound their database with small queries. This design pattern has the potential to hide such problems by the sheer increase in performance that it grants by reducing the number of database connections to one. I would emphasize that you not rely on this design pattern as a foundation for your application’s data tier performance, and instead make sure you don’t have chatty apps before “turning it on,” so to speak. Ensure that in the absence of this design pattern your application still performs at an acceptable level.
Difficult or Time Consuming to Retrofit into Legacy Applications
If you are examining an existing system or application and you would like to find a way to apply this design pattern, but the system in question does not currently have well organized code for its data access tier, you may find yourself in a sinkhole of time. I am sure you would love to spend all the time in the world honing your data access tier to the Nth degree, but some older application that were not architected properly (or at all) can not only prove difficult to retrofit with this design pattern but, at the very least, very time consuming. If you are in a crunch for time, this may not be the best option if you are looking for performance gains with your data tier.
Table Locking Issues
Depending on the isolation level chosen for your transaction, you have the potential to cause locking issues with the back-end database. Long running transactions can adversely affect the performance of other users running queries on the same table, so you need to make sure your application minimizes the amount of time it maintains the transaction.

Sample Code

I am going to present sample code using a web application for ASP.NET in C#, but it can easily be converted into VB.NET. In an effort to make this example as portable as possible without any configuration changes on the part of the person downloading the sample, I will also utilize an Access Database. I will program to an interface, so switching out the data provider from Jet to SQL will be trivial.

In the world of ASP.NET, this design pattern is best implemented using an HTTP module. This means you need only implement the System.Web.IHttpModule interface and define it in the appropriate location in your web.config file (//configuration/system.web/httpModules for IIS6 or //configuration/system.webServer/modules for IIS7). The HTTP module implementor is supported by a session manager class that allows thread-safe access to the connection and transaction, and both of them are usually implemented and visible only to the data tier of your application (assuming a 3-tier architecture).

Session Manager

The source code to the real workhorse behind this design pattern is the Session Module:

using System;
using System.Collections.Generic;
using System.Text;

namespace CSharpOSIV
{
    /// 
    /// The main entry point for the Open Session In View Design Pattern that
    /// allows access to the current thread's connection and transaction objects
    /// 
    /// 
    /// An interesting characteristic of this class is that it exposes the connection
    /// and transaction objects that are specific to the current thread, but only a single
    /// instance of it is ever created, which follows the Singleton Design Pattern.
    /// 
    public sealed class SessionManager
    {
        /// 
        /// The key used when storing the connection in web or call context
        /// 
        private const string THREADCONNECTION_KEY = "THREADCONNECTION_KEY";

        /// 
        /// The key used when storing the transaction in the web or call context
        /// 
        private const string THREADTRANSACTION_KEY = "THREADTRANSACTION_KEY";

        /// 
        /// This class is exposed as a singleton and this static variable contains the instance
        /// 
        private static SessionManager _Instance = null;

        /// 
        /// Private constructor so it can only be accessed with the singleton
        /// 
        private SessionManager()
        {
            // make sure the Session Module is registered in the web.config
            MakeSureModuleIsInWebConfig();
        }

        /// 
        /// This utility method will make sure that the web.config entry exists, which is required for this manager to function properly
        /// 
        private static void MakeSureModuleIsInWebConfig()
        {
            // we only check the web.config if we are within a web context
            if (IsInWebContext)
            {
                using (var fileStream = System.IO.File.OpenRead(System.AppDomain.CurrentDomain.SetupInformation.ConfigurationFile))
                {
                    var doc = new System.Xml.XPath.XPathDocument(fileStream);
                    var nav = doc.CreateNavigator();

                    // IIS6 and IIS7 store the HTTP Module sections in different locations so we need to check both
                    bool foundForIis6 = ModuleExists(nav, "/configuration/system.web/httpModules/add/@type");
                    bool foundForIis7 = ModuleExists(nav, "/configuration/system.webServer/modules/add/@type");

                    if (!(foundForIis6 || foundForIis7))
                    {
                        // The HTTP Modules section is either missing or does not have the SessionModule defined in its list
                        throw new Exceptions.SessionModuleNotRegisteredException();
                    }
                }
            }
        }

        /// 
        /// This utility method checks for a specific module in the specified location of the web.config file's HTTP Modules section
        /// 
        /// The XPathNavigator that allows for navigation to the proper node
        /// The path that should be checked
        /// 
        private static bool ModuleExists(System.Xml.XPath.XPathNavigator nav, string xpathToTypeAttribute)
        {
            bool result = false;
            foreach (System.Xml.XPath.XPathNavigator node in nav.Select(xpathToTypeAttribute))
            {
                string sType = node.ToString();
                if (!String.IsNullOrEmpty(sType))
                {
                    Type t = System.Type.GetType(sType, false, true);
                    if (typeof(SessionModule).Equals(t))
                    {
                        result = true;
                        // once we find the HTTP module we can cut out early
                        break;
                    }
                }
            }
            return result;
        }

        /// 
        /// Expose a singleton for the session manager
        /// 
        public static SessionManager Instance
        {
            get
            {
                if (_Instance == null)
                {
                    // this string, which is defined as a constant, is already interned, 
                    // which makes it a suitable object on which to lock with the monitor
                    lock (THREADCONNECTION_KEY)
                    {
                        if (_Instance == null)
                        {
                            _Instance = new SessionManager();
                        }
                    }
                }
                return _Instance;
            }
        }

        /// 
        /// Is the current thread functioning within a web context?
        /// 
        private static bool IsInWebContext
        {
            get { return System.Web.HttpContext.Current != null; }
        }

        /// 
        /// The thread-specific connection for the current request
        /// 
        private System.Data.IDbConnection ThreadConnection
        {
            get
            {
                if (IsInWebContext)
                {
                    return System.Web.HttpContext.Current.Items[THREADCONNECTION_KEY] as System.Data.IDbConnection;
                }
                else
                {
                    return ReadCallContext(THREADCONNECTION_KEY);
                }
            }
            set
            {
                if (IsInWebContext)
                {
                    System.Web.HttpContext.Current.Items[THREADCONNECTION_KEY] = value;
                }
                else
                {
                    StoreInCallContext(THREADCONNECTION_KEY, value);
                }
            }
        }

        /// 
        /// The thread-specific transaction for the current request
        /// 
        private System.Data.IDbTransaction ThreadTransaction
        {
            get
            {
                if (IsInWebContext)
                {
                    return System.Web.HttpContext.Current.Items[THREADTRANSACTION_KEY] as System.Data.IDbTransaction;
                }
                else
                {
                    return ReadCallContext(THREADTRANSACTION_KEY);
                }
            }
            set
            {
                if (IsInWebContext)
                {
                    System.Web.HttpContext.Current.Items[THREADTRANSACTION_KEY] = value;
                }
                else
                {
                    StoreInCallContext(THREADTRANSACTION_KEY, value);
                }
            }
        }

        /// 
        /// Utility method that stores data into the call context dictionary
        /// 
        /// 
        /// Call Context class cannot be referenced in a medium-trust environment so it is refactored 
        /// to a different method to prevent the ThreadConnection and ThreadTransaction properties from
        /// throwing security exception.
        /// 
        /// The key into which the object should be stored in the call context
        /// The object to store into the call context
        private static void StoreInCallContext(string key, object obj)
        {
            // The following call requires higher permissions than those available in a medium-trust environment
            // so the compiler should not in-line it, but if it does just move this method to a utility project
            System.Runtime.Remoting.Messaging.CallContext.SetData(key, obj);
        }

        /// 
        /// Utility method that retrieves data from the call context dictionary
        /// 
        /// 
        /// Call Context class cannot be referenced in a medium-trust environment so it is refactored
        /// to a different method to prevent the ThreadConnection and ThreadTransaction properties from
        /// throwing a security exception.
        /// 
        /// The type of object that will be returned
        /// The key into the dictionary from which you should read
        /// 
        private static T ReadCallContext(string key)
        {
            // The following call requires higher permissions than those available in a medium-trust environment
            // so the compiler should not in-line it, but if it does just move this method to a utility project
            return (T)System.Runtime.Remoting.Messaging.CallContext.GetData(key);
        }

        /// 
        /// Does the current thread have an open connection?
        /// 
        private bool HasOpenConnection
        {
            get
            {
                return (this.ThreadConnection != null &&
                        this.ThreadConnection.State == System.Data.ConnectionState.Open);
            }
        }

        /// 
        /// Does the current thread have an open transaction?
        /// 
        private bool HasOpenTransaction
        {
            get
            {
                return (this.ThreadTransaction != null);
            }
        }

        /// 
        /// Starts the transaction using the specified data provider
        /// 
        public void StartTransaction()
        {
            if (!HasOpenConnection) OpenConnection();
            if (!HasOpenTransaction) OpenTransaction();
        }

        /// 
        /// Utility method that opens the connection to the database if one does not already exist
        /// 
        private void OpenConnection()
        {
            System.Data.IDbConnection connection = ThreadConnection;

            if (connection == null)
            {
                // TODO: Make this more abstract and configurable through the web.config entry
                // but for now this will suffice for demonstration purposes
                connection = new System.Data.OleDb.OleDbConnection(System.Configuration.ConfigurationManager.ConnectionStrings["JetDB_OSIV"].
                    ConnectionString.Replace("~", System.Web.HttpContext.Current.Server.MapPath("~/")));
                connection.Open();
                // encapsulate the connection object with the wrapper class, which protects certain methods from execution
                connection = new Wrappers.ConnectionWrapper(connection);
                this.ThreadConnection = connection;
            }
        }

        /// 
        /// Utility method that starts the transaction with the database if one does not already exist
        /// 
        private void OpenTransaction()
        {
            System.Data.IDbConnection conn = ThreadConnection;
            System.Data.IDbTransaction trans = ThreadTransaction;
            if (conn != null && trans == null)
            {
                if (conn is Wrappers.ConnectionWrapper)
                {
                    trans = ((Wrappers.ConnectionWrapper)conn).ManualBeginTransaction();
                }
                else
                {
                    trans = conn.BeginTransaction();
                }
                ThreadTransaction = trans;
            }
        }

        /// 
        /// Commit the transaction and close the connection with the database
        /// 
        public void CommitTransaction()
        {
            if (HasOpenTransaction) FlushTransaction();
            if (HasOpenConnection) CloseConnection();
        }

        /// 
        /// Executing the flush operation with the database using the current transaction
        /// 
        private void FlushTransaction()
        {
            System.Data.IDbTransaction trans = ThreadTransaction;

            if (trans != null)
            {
                try
                {
                    if (trans is Wrappers.TransactionWrapper)
                    {
                        ((Wrappers.TransactionWrapper)trans).ManualCommit();
                    }
                    else
                    {
                        trans.Commit();
                    }
                }
                catch (System.Exception ex)
                {
                    throw new Exceptions.SessionTransactionException(ex);
                }
                finally
                {
                    if (trans is Wrappers.TransactionWrapper)
                    {
                        ((Wrappers.TransactionWrapper)trans).ManualDispose();
                    }
                    else
                    {
                        trans.Dispose();
                    }
                    ThreadTransaction = null;
                }
            }
        }

        /// 
        /// Closes the current connection to the database
        /// 
        private void CloseConnection()
        {
            System.Data.IDbConnection conn = ThreadConnection;

            if (conn != null)
            {
                try
                {
                    if (conn is Wrappers.ConnectionWrapper)
                    {
                        ((Wrappers.ConnectionWrapper)conn).ManualClose();
                    }
                    else
                    {
                        conn.Close();
                    }
                }
                catch (System.Exception ex)
                {
                    throw new Exceptions.SessionConnectionException(ex);
                }
                finally
                {
                    if (conn is Wrappers.ConnectionWrapper)
                    {
                        ((Wrappers.ConnectionWrapper)conn).ManualDispose();
                    }
                    else
                    {
                        conn.Dispose();
                    }
                }
            }
        }

        /// 
        /// Rolls the current transaction back and closes the connection
        /// 
        public void RollbackTransaction()
        {
            if (HasOpenTransaction) Rollback();
            if (HasOpenConnection) CloseConnection();
        }

        /// 
        /// Executes the rollback unit of work
        /// 
        private void Rollback()
        {
            System.Data.IDbTransaction trans = ThreadTransaction;

            if (trans != null)
            {
                try
                {
                    trans.Rollback();
                }
                catch
                {
                    // ignore errors - in a production environment you would log this event
                }
                finally
                {
                    if (trans is Wrappers.TransactionWrapper)
                    {
                        try { ((Wrappers.TransactionWrapper)trans).ManualDispose(); }
                        catch { }
                    }
                    else
                    {
                        try { trans.Dispose(); }
                        catch { }
                    }
                }
            }
        }

        /// 
        /// Retrieves the current thread's connection
        /// 
        /// The connection object for the current thread
        public System.Data.IDbConnection GetConnection()
        {
            return this.ThreadConnection;
        }

        /// 
        /// Retrieves the current thread's transaction
        /// 
        /// The transaction object for the current thread
        public System.Data.IDbTransaction GetTransaction()
        {
            return this.ThreadTransaction;
        }

    }
}

The session manager’s job is to store the connection and transaction objects safely for later retrieval by the rest of your data access tier. In ASP.NET, this is accomplished using the HTTP Items collection because it is unique to the thread currently being used to serve up the current request. You will also note that in the absence of this collection (i.e. an application context), it reverts to the use of the call context, which functions in a similar manner.

You may have a few questions about this code, and I will try to answer the most obvious ones below:

If the HTTP Items collection is only available in a web context, and the call context is available in both contexts, why not always use the call context?
The answer to this question is quite complex, but suffice it to say that within a web context the call context can “lose” the data you store in it, especially in high-traffic scenarios, which makes it an unreliable storage medium for these objects. Second, if you are using a web application that must function in a medium-trust environment, you will be unable to even reference the call context class, which requires greater permissions than those granted under that scenario. However, if you are functioning within an application context (there is not web-context to deal with), then you are free to use it safely just like the HTTP context because in such a scenario it does not suffer this issue.

NOTE:Despite my admittedly vague explanation above as to why the web context HTTP items collection should be used instead of the Call Context, it should be noted that the HTTP Items collection is stored in the call context. I will leave the reason for this as an exercise for the reader (because I’m lazy and don’t feel like explaining it).
Why doesn’t this fail when more than a single user is using the website?
The Session Manager class essentially converts a statically visible dictionary into an instance dictionary suitable for use by any thread serving up an HTTP request, which is why I think it is such a creative solution. The HTTP Items collection is specific to the current thread serving the HTTP request just like the Call Context is specific to the current application thread in a Win Forms application. This allows the whole class to be exposed as a singleton (minimizing overhead for the entire application) and allows the rest of your application the comfort of being completely oblivious to what is really happening. This is a great example of encapsulation doing exactly what it should be doing with something more complex than a simple getter/setter.
Wait, couldn’t my code inadvertently close the connection or commit the transaction after getting it from the session manager?
The short answer to this question is yes. However, through a creative use of the IDbConnection, IDbTransaction, and IDbCommand interfaces, you can circumvent this problem. The sample code provided addresses this issue. The Session Module specifically checks for the wrapper types and calls non-interface defined methods to close and dispose of the managed objects. A further optimization is to expand the code so that a connection is never even opened to the database unless a command is actually executed, but the sample code provided does not address this scenario for brevity.

Session Module

The controller behind this design pattern is the session module. It is this HTTP module that controls when the connection is created at the beginning of the request and when the transaction is committed at the end of it. It is also responsible for making sure the transaction is rolled back in a situation where an error occurs. The implementation of the Session Manager makes this class’s implementation fairly trivial, which you will notice in the sample code below:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace CSharpOSIV
{
    /// 
    /// An HTTP Module that permits the use of an open session in view design
    /// pattern by starting the transaction at the beginning of the HTTP request
    /// and committing it to the database at the end of the request.
    /// 
    public sealed class SessionModule : System.Web.IHttpModule
    {
        void System.Web.IHttpModule.Init(System.Web.HttpApplication context)
        {
            context.BeginRequest += new EventHandler(context_BeginRequest);
            context.EndRequest += new EventHandler(context_EndRequest);
        }

        void context_BeginRequest(object sender, EventArgs e)
        {
            SessionManager.Instance.StartTransaction();
        }

        void context_EndRequest(object sender, EventArgs e)
        {
            try
            {
                SessionManager.Instance.CommitTransaction();
            }
            catch
            {
                SessionManager.Instance.RollbackTransaction();
            }
        }

        void System.Web.IHttpModule.Dispose()
        {
            /* nothing to do */
        }

    }
}

The basic premise is that this module starts the database connection and transaction and cleans it up after the web request is finished. All of the necessary methods are present on the Session Manager.

Other Considerations

A few more points of interest regarding this design pattern include, but are not limited to, the following topics:

Impact of Connection Pooling
The data provider for your database can usually be configured to use connection pooling (even Access Databases can do this, see the following link: http://msdn.microsoft.com/en-us/library/ms724518(VS.85).aspx. Connection pooling is just another component for increasing performance in data-intensive web applications that complements, but does not make irrelevant, the design pattern discussed here.
Read-Only Transactions
Depending on the application, you may be able to further increase performance by fine tuning the isolation specified in your ASP.NET application by choosing the appropriate isolation level. Again, this depends entirely on the application, critical nature of the data, and concurrency issues, but using read-only transactions has the potential to further increase the performance of your database connection. The ability to apply this principle, however, may be nearly impossible in a real environment due to the inability to detect what types of queries are going to be executed (the sample project suffers from this problem so no isolation level is even specified).

I could continue rambling on about the merits of this design pattern and its applications forever, but I will allow the sample solution file to speak for itself. I believe the information presented above and in the sample project file should give a good primer the Open Session In View design pattern. I look forward to hearing feedback and comments regarding the sample code and thoughts and suggestions about ways it can be improved.

Credits

I would like to make sure I give credit to others who inspired me to create the solution that is attached to this blog entry. I didn’t come up with most of the concepts completely on my own, but I did build on them quite a bit.

http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx
https://www.hibernate.org/43.html

License

This source code is licensed under the GNU Lesser General Public License. I would appreciate credit if you use this source code as a base for any implementation and would especially love to know where it has been applied!

Sample Project Download

You can download the sample project by clicking on the following link: Download ZIP of Solution

Cirrus ABS » C#