Context Lifetimes -- Dispose or Reuse?

Here's another topic which I believe is important to educate more folks on, but I just haven't had the time to carefully write something up.  As I was answering a question on the forum today, I realized that the answer might be good to share a bit more broadly, so here's a copy of that response.  The question which has come up several times is "When do I dispose of a context and recreate it vs when should I keep the existing context around and re-use it?"

If you are building a rich client application then you may well want to keep a context around for the life of the application, but you need to keep track of how many entities you have in that context.  It's all about understanding the overall pattern of your app.  There are some extremes and a whole spectrum of possibilities across the middle.

• If your app's purpose is to efficiently add 200,000 entities to the database and then quit, then I would recommend doing batches rather than trying to cram all of them into the context at once and do one big save.  (This will clearly yield better performance.)

• Similarly, if you are building a web service or asp.net app, then I would recommend spinning up a new context on every request in order to keep the server stateless.

• At the other end of the spectrum you might have a rich client application that typically deals with a fairly small amount of data over its entire lifetime (think something like office communicator where you don't persist the discussions at all but you have a list of contacts and the typical size of that is small enough that if it all gets loaded into memory it wouldn't be that big a deal).  For this case I'd probably use one context for the life of the app and not worry about it.

• In the middle somewhere come things like a rich client email or order entry app where there's some amount of data which is relatively constant in size and relatively small (the contacts you work with regularly, the products you usually sell or reference data like zipcode->state map or something) plus some amount of data that is transient (email messages arriving, being read and deleted, or orders entered and then sent off for processing).  In this kind of application I would use a single context and then keep careful track of what data is which kind.  For the "re-usable" data I would just leave it in the context, and for the transient data I would make sure that when I know it is no longer needed that I call Detach on it.  The detach method on the object context will remove items from the context without destroying it.  If you have a LARGE batch of items attached to a context, then the fastest thing generally is to destroy the context and recreate it (metadata caching will make this relatively fast), but if your context has some data you want to keep and some you want to detach, then you can call the detach method on everything you want to detach and continue using the context.

As one of my high-school math teachers used to say, clear as mud?

 - Danny