Alex D James
7 3:44 PM
One of the most common questions we get are how long should an ObjectContext should live. Options often cited include one per:
- Function
- Form
- Thread
- Application
Plenty of people was asking these types of questions, case at point where is a question on stackflow. I am sure there is many more buried away in our forums too.
This is a classic it depends type of question.
Lots of factors weigh into the decision including:
- Disposal:
Cleanly disposing of the ObjectContext and it ' s resources is important. It is also significantly easier if you create a new ObjectContext for each Function, because then can simply write a U Sing block to ensure resources is disposed appropriately:
using (mycontext CTX = new Mycontext ())
{
...
}
- Cost of construction:
Some people is, quite understandably, concerned about the cost of recreating the objectcontextagain and again. The reality is the actually pretty low, because mostly it simply involves copying, by reference, metadata from a Global cache into the new ObjectContext. Generally I don ' t think this cost is worth worrying on, but as always, there would be exceptions to that rule.
- Memory Usage:
The more your use of an ObjectContext, generally the bigger it gets. This was because it holds a reference to all the entities it had ever known about, essentially whatever we have queried, a Dded or attached. So you should reconsider sharing the same ObjectContext indefinitely. There is some exceptions to that rule and a workaround, but for the most part these approaches just aren ' t recommended.
- If your ObjectContext only ever does NoTracking queries then it won ' t get bigger because the ObjectContext immediately for Gets about these entities.
- You could implement some very explicit tidy-up logic, i.e. implement some sort of Recycle interface, that iterates through The Objectstatemanager detaching entities andacceptingchanges (..) to discard deleted objects. Note: I ' m not recommending this, I ' m just saying it should be possible, I has no idea if relative to recreation it would result In any savings. So this might is a good subject for a future blog post.
- Thread Safety:
If you were trying to re-use a ObjectContext you should being aware that's not a thread safe, i.e. similar to the standard. NET collection classes. If you access it from many threads (e.g. Web requests), you'll need to insure, that's you synchronize access manually.
- Stateless:
If your services is designed to being stateless, as most Web services should be, re-using anobjectcontext between requests m Ight not is best because, the leftovers in the ObjectContext from the last call may has subtle effects on your applicatio n that is not expecting.
- Natural finite lifetimes:
If you have a natural finite lifetime the managing a Objectcontext,such as a short lived Form, aunitofwork or a Reposi Tory, then scoping the ObjectContext accordingly might is the best thing to do.
As you can see there is lots of issues at play.
Most of the them tend to point towards a short lived context that isn ' t shared.
So, is my recommended rule of thumb.
However as always understanding the reasoning behind a ' rule of thumb ' would help you know when it's appropriate to go R.
Other reference managing DbContext the right-of-the-6:an in-depth guide for re-initiate the DbContext when using The Entity Framework?
Tip 18–how to decide on a lifetime for your ObjectContext
