Share via

Miscellaneous

  • Article

Part of the Entity Framework FAQ .

18. Multi-threading

18.1.What is the recommendation for running a multithreaded application on Entity Framework? Is Entity Framework thread-safe?

Entity Framework, like most of the rest of the .Net framework, is by and large NOT thread-safe. So if you want to interact with the entity framework or your entity classes from multiple threads, then you are going to have to do your own locking. One simple model which works for some cases is for each thread to maintain its own context so that no locking is required. This means, of course, that the interactions between the threads tends to be quite limited (you can’t really pass an entity from one thread to another without being very careful), but you can do some pretty useful things even so.

Pasted from <blogs.msdn.com/dsimmons/>

19. Performance

19.1.What does query plan caching do? Do I need to keep my ObjectQuery<T> around to take advantage of query plan caching?

Query plan caching stores information which is computed as part of putting together the query itself. By caching this, a subsequent execution of the same query (even if you change parameter values) will run much faster than the first one. This information is cached per app-domain so you will generally benefit from the query cache across multiple client requests to the same web app and the like.

You do not have to keep an ObjectQuery<T> instance around to take advantage of the query plan cache--future ObjectQuery<T> instances which use the same query string will automatically take avantage of it. For more information, see Performance Considerations for Entity Framework Applications.

Pasted from <forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2363212&SiteID=1>

19.2.Show me the numbers. How good is EF performance?

Take a look at some relevant posts on the ADO.Net team blog starting with this one: blogs.msdn.com/adonet/archive/2008/03/27/ado-net-entity-framework-performance-comparison.aspx. For more information, see Performance Considerations for Entity Framework Applications.

20. Resource Management

20.1.What should be the lifetime of Object Context? Should I create a new Object Context for every new query?

This is a broad topic and obviously the right answer varies a lot depending on the overall architecture of the app you are building—if you are building a web service or an asp.net page then you almost certainly want the context only to stay alive during each request and then be destroyed so that your server can be as stateless as possible, but if you are building a rich client application, then your context will typically stay alive for a much longer period of time—in fact the same context probably stays alive for the life of your app. The reason for this is that the context performs identity resolution and provides the path from entities to the database for when you want to do things like deferred loading. If you destroy the context or detach the entities from it, then deferred loading won’t work.

The other thing you have to remember, though, is that the EF, like most of the rest of the .Net framework, is by and large NOT thread-safe. So if you want to interact with the EF or your entity classes from multiple threads, then you are going to have to do your own locking. One simple model which works for some cases is for each thread to maintain its own context so that no locking is required. This means, of course, that the interactions between the threads tends to be quite limited (you can’t really pass an entity from one thread to another without being very careful), but you can do some pretty useful things even so.

20.2.Does the provider connection stay open for the entire life time of Object Context? When is the provider Connection opened/closed?

The Object Context keeps the connection closed as much as possible while still appropriately dealing with transactions and avoiding promotion of those transactions from local to DTC where possible. The Object Context does NOT keep the connection open from the time ObjectContext was constructed till the life of the context; because this would create issues, for instance, with databases where licensing was based on the number of concurrently open connections since the connection might be held open for an extended period of time—even when the connection is not being used.

You can also exercise more explicit control over the connection by manually opening or closing it. If you open the connection, for instance, the context will leave it open until you explicitly close it or the context is disposed. For more information, see Managing Connections in Object Services (Entity Framework).

20.3.Do I need to explicitly call Dispose() on ObjectContext object after use?

The short answer; no, you don't have to, but you should...

ObjectContext holds state (for example, a SqlConnection and pointers to the objects you have retrieved). These will eventually get cleaned up by the GC once you release all references, but some of these objects (for example, the underlying SqlConnection) may be holding resources that you typically want to release as soon as your are finished, rather than relying on the GC to clean up.

We generally recommend constructing a ObjectContext within a using statement to make sure that resources are cleaned up when you leave the block. For example, in C# we would recommend:

using(NorthwindObjectContext db = new NorthwindObjectContext())

{

     //do stuff with ObjectContext

} // Dispose is called on ObjectContext when you leave the using block

 

This is the same pattern we recommend for using DbConnections in ADO.NET 2.0. . For more information, see Managing Resources in Object Services (Entity Framework).

Pasted from <forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2354870&SiteID=1>

Comments