Why is an explicit Dispose() function required in asp.net MVC Controllers? Can somebody clarify the complexities? (special to ASP.NET)

asp.net-mvc c# entity-framework garbage-collection idisposable

Question

I know C# can manage resource pretty well with its garbage collector. But since it has that, what exactly is this for and why is it needed?

Can anyone explain why .Dispose() is needed in asp.net mvc?

Also, what does it mean to Dispose a connection? Why is it needed? Anyone know the intricacies of why it's important to dispose a database connection like in db.Dispose()? Is this EF-related, or SQL Server-related? I'm trying to understand exactly why.

protected override void Dispose(bool disposing)
{
   db.Dispose();
   base.Dispose(disposing);
}
1
29
4/13/2012 2:38:24 AM

Accepted Answer

Dispose is for releasing "unmanaged" resources (for example, sockets, file handles, Bitmap handles, etc), and if it's being called outside a finalizer (that's what the disposing flag signifies, BTW), for disposing other IDisposable objects it holds that are no longer useful.

"Unmanaged" resources aren't managed by the CLR (hence the name), and GC doesn't mess with them or free them all by itself; absent a Dispose method (and code actually using it!), it'll rely on the object's finalizer to clean up. Eventually the finalizer will run (if the app's healthy, and the object has a finalizer), and if the finalizer does its job then all's semi OK....but it'll take its sweet time in doing so -- and if you run out of handles in the meantime, oh well. Too bad for that other thread/process/whatever that needed them.

If you Dispose, though, the resources are released immediately, and things run better all around.

(By the way, this is not restricted to EF, SQL Server, or any other technology. The Disposable pattern is found throughout the .net framework, and it's considered good practice to take advantage of it whenever you have an IDisposable that's no longer being used.)

As for why IDisposable is implemented so far up the tree, rather than you just implementing it on a case by case basis...i'm not 100% sure. But imagine you were writing a framework. Consider that if everything weren't an IDisposable, you'd have to check -- every time you wanted to get rid of something! -- whether the object is disposable, and Dispose it if so. If you instead implement IDisposable "just in case", though, things are simplified -- you just always dispose. (If an object doesn't have anything to clean up, it just doesn't override Dispose -- in which case its parent's Dispose gets called and does whatever cleanup it has to, which may be nothing as well...) And it's a common enough case for controllers to have stuff to clean up, that even if that's not the real reason, it makes a lot of sense to do anyway.

28
4/13/2012 3:43:13 AM


Related Questions





Related

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