Entity framework and deataching objects

Question

When building a web application that uses entity framework in its data access layer, it is recommended to detach objects from the object context to allow objects to be garbage collected.

But since the web applications are all request -> response applications, the object context itself is not referenced any more by any live objects after the response is sent to the customer, and so the object context and its attached object should be available for garbage collection, since there is no live object referencing any of them.

Am I missing something here or detaching objects in not necessary in such scenario?

Answer 1

Muhammad, I cannot speak to the EF, but as it relates to Linq-to-SQL, detaching an object doesn't have anything to do with garbage collection. It has to do with detaching an object from a database context so it can be attached to another object. This is a very common thing to do in a stateless (n-tier) application. The same may apply to the EF.

Randy

Answer 2

This article will probably help you. The EF was designed like NHibernate with a stateful session/context by default (i.e. a windows forms application). This may have changed since version 1, which was when I last look at it. It's a bit strange though, given that most people will be using it for websites - much like NHibernate makes you use session-per-request and wasn't primarily designed with websites in mind.

The idea is you're not meant to worry about updates or inserts, it's all done automatically for you. That increases memory usage but when it's properly managed by your application that usually increases the performance than reducing it.

Answer 3

In the EF if you have to use more than one context like in a n-tier application, or if you want to create a entityCollection you need to detach the entity. But is not a demanding implementation for asp.net application

Answer 4

Assuming you are not keeping the object context around(holding a reference to it in some way), once it goes out of scope it will be garbage collected. I can't see any need to detach entities.

So, I don't think you are missing anything.

Answer 5

I suspect the guidance you saw was talking about No-Tracking queries

No-Tracking queries definitely have some performance benefits for read intensive web-sites.

Objects are never attached, and tracked by identity, so you don't need to detach them, which avoids the cost of doing identity resolution during the materialization.

A no-tracking query looks like this:

var source = ctx.Staff;
source.MergeOption == MergeOption.NoTracking;

var staff = (from s in source
             where s.ID == 12 
             select s).First();

No tracking queries have another benefit over manually detaching entities: Manually detaching disconnects the entity from the rest of its entity Graph, where as, with no tracking queries you can retrieve a connected graph of entites that are all detached.

But there are some downsides to using non-tracking queries too: You can occasionally end up in situations where you read duplicate results because you've turned off identity resolution.

So unless you are really confident that your query is only going to return one copy of each entity, you should be careful, or you might end up with a UI bug.

Hope this helps

Alex

PS: This tip on ObjectContext lifetime might be helpful for you.