Connection Pooling and Entity Framework

.net connection-pooling database entity-framework


Recently, I began using the Entity Framework 4.0 in my.NET 4.0 application, and I have some questions about pooling.

  1. As far as I'm aware, the ADO.NET data provider, in my case the MS SQL server, is responsible for managing connection pooling. Does this apply when a new entity context is instantiated?ObjectContext ), or the parameter-freenew MyDatabaseModelEntities() ?

  2. What are the benefits and drawbacks of a) generating an application-wide global entities context (i.e., one static instance) or b) constructing and exposing an entities context for each specific operation or function, with ausing block.

  3. Any more advice, suggestions, or typical methods for certain situations that I need to be aware of?

9/6/2010 4:42:47 PM

Accepted Answer

  1. The same procedures apply to connection pooling in all other ADO.NET applications. Conventional database connections and traditional connection strings are still used by entity connections. If you don't want to utilize connection pooling, I think you may disable it in the connection string. (Learn more about 7-Zzz here)
  2. Global context should never be used. Internally, ObjectContext uses a number of patterns, including Identity Map and Unit of Work. The effects of employing global context vary by application type.
  3. Utilize a single context per request for web apps. Use a single context per call for web services. Use one context per form or presenter in a WinForms or WPF application. Although there may be certain unique conditions that prevent the adoption of this strategy, it is usually sufficient.

Check out this article to learn the effects single object context has on WPF and WinForm applications. NHibernate Session is the subject, but the concept is the same.


When using EF, each object is by default loaded just once per context. The first query generates the item from scratch and internally stores it. This saved instance is returned by any future query that needs an entity with the same key. You still obtain the entity with the values from the original query even if the values in the data store changed. It's known as Pattern identity mapping. Although you may have the object context reload the entity, only one shared instance will be loaded.

Until you call, any modifications you make to the entity do not take effect.SaveChanges on the surroundings. Changes may be made simultaneously and stored for numerous entities. It's known as Pattern of Unit of Work. You cannot specify which updated associated entity you wish to save in a selective manner.

You will see some intriguing results if you combine these two patterns. For the duration of the application, there is only one instance of the entity. Even if modifications have not yet been persisted, any changes to the object have an impact on the whole application (commited). Most of the time, you don't want this. Let's say your WPF application has an edit form. While collaborating with the entity, you decide to revoke advanced editing (changing values, adding related entities, removing other related entities, etc.). The entity, however, has already been altered in a shared context. How will you proceed? Observation: I am unaware of any CancelChanges or UndoChanges onObjectContext .

I don't believe the server case has to be discussed. Your application becomes meaningless if you just share a single object across several HTTP requests or Web service calls. Any request might simply set offSaveChanges and store a portion of the data from another request since each of them is sharing a single unit of labor. This will also have another issue since the context, along with any modification of context-related items or database connections, is not thread-safe.

A global context is not a wise option, even for read-only applications, since you presumably want new data each time you query the application.

7/2/2014 12:51:08 PM

Popular Answer

In line with Daniel Simmons

Create a new ObjectContext instance in a Using statement for each service method so that it is disposed of before the method returns. This step is critical for scalability of your service. It makes sure that database connections are not kept open across service calls and that temporary state used by a particular operation is garbage collected when that operation is over. The Entity Framework automatically caches metadata and other information it needs in the app domain, and ADO.NET pools database connections, so re-creating the context each time is a quick operation.

This is from his in-depth article located here:

This suggestion, in my opinion, applies to HTTP requests as well, making it appropriate for ASP.NET. A "shared" context could only exist in stateful, fat-client applications like WPF ones.

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow