How long should a DataContext live?

Question

I was just wondering how long should a DataContext really live. All the patterns and practices books like Dino Esposito's Microsoft .NET: Architecting Applications for the Enterprise tell you, datacontext must not live long, nor should it be cached. But how long is the right time? A whole web request, a unit of work, a transaction, only one query at a time? (I assume a web request has usually more than just one unit of work)

Lets say you use the Entity Framework as a ORM Tool in a web application. But what about the Identity Map Pattern in this scenario. Lets say you've got a dedicated instance of a Customer DAL, which creates a Datacontext and another Invoice DAL, which it self creates a new DataContext for its purpose as well. If you would have gotten a base class for all DALs, that creates a single instance of the ObjectContext and dispose this one at the end. Would that be considered a bad implementation? It could make sense to just have one ObjectContext for a single web request, in my opinion. It could make use of the supported Identity Map Pattern by the Entity Framework as just one advantage.

Any ideas, comments, thoughts or criticism?

Answer 1

The lifetime of a data context should be equivalent to a unit of work in the application. In web applications this unit of work correlates with a request. The request comes in and the server processes it in one go. At the end of the request all changes made by this request get persisted in the database. That is the usual behaviour in a web application, where most of the requests match a single user action.

Therefore there should only be one data context per request. This makes sense not only in terms of the unit of work pattern, but also in respect to performance considerations. A data context is a heavyweight object, that is expensive to construct. The advantage of the first level cache, that comes out of the box with all OR Mapping tools through their implementation of the Identity Map Pattern necessity, underlines the use of only one data context even further.

ASP.NET has 2 events in their application and page life cycle that facilitates the implementation.

1. Application_BeginRequest: Authorise the creation of the datacontext.
2. Application_EndRequest: Authorise the dispose of the datacontext.

I choose the use of the word authorise wisely, since the web application doesn't necessarily need to create the data context it self directly, but rather call a method on a SessionFactory object to instanciate the data context.

All Data Access Layer objects or repositories can than call the SessionFactory to obtain the current data context.

The code for Global.asax looks like this:

public static ISessionFactory SessionFactory { get; private set; }

void Application_Start(object sender, EventArgs e)
{
           SessionFactory = new SessionFactory();
}

void Application_BeginRequest(object sender, EventArgs e)
{
    var session = SessionFactory.OpenSession();
}

void Application_EndRequest(object sender, EventArgs e)
{
    SessionFactory.DisposeSession();
} 

Answer 2

The simplest thing to do is dispose of the DataContext as soon as possible. That said you can keep the DataContext around as long as you want, as long as you are willing to deal with the headaches that will cause.

Like many things, the answer is "it depends" and is situation dependent. There is no single answer.

For web apps, keeping a DataContext around for the life of a web request is generally pretty straight forward to deal with.

I would suggest you start with small lifetimes and then increase the lifetime in situations where you need the caching and other benefits of longer life DataContexts.

Answer 3

Alex James wrote a good article about this. In it, he notes you need to consider:

• Disposal
• Cost Of Construction
• Memory Usage
• Thread Safety
• Statelessness
• Natural finite lifetimes