Dan Wahlin's WebLog - All Comments

re: What If I Don’t Call Dispose() on my LINQ to SQL DataContext Object?

dwahlin — Thu, 21 Aug 2008 07:24:36 GMT

Paul and Craig,

Thanks for the additional details. Good stuff with the finalizers (something I haven't had to think much about for awhile). It reenforces the fact that we all need to keep wrapping IDisposable objects in "using" blocks which has always been considered "best practice" anyway.

re: What If I Don’t Call Dispose() on my LINQ to SQL DataContext Object?

PaulWilson — Wed, 20 Aug 2008 21:41:39 GMT

Here's the "typically" details:

The .NET Garbage Collector never ever worries about IDisposable. What it does worry about is finalizers. If an object has a finalizer that hasn't been suppressed then it won't be released in the first GC pass. And "typically" objects that implement IDisposable have finalizers, since you probably would want to make sure that your "Dispose" logic is called even if the Dispose method itself is not called. But I've seen some IDisposable objects that do not have finalizers, and I think I've even seen some in the framework itself when there wasn't anything really useful in the Dispose method anyhow. But again, you shouldn't make unnecessary assumptions -- if it implements IDisposable then you should call Dispose (via a using block in most cases), and you should assume it could cost you extra GC cycles if you don't.

re: Using LINQ to SQL XML Mapping Files – Step by Step

Jim Wooley — Wed, 20 Aug 2008 20:58:42 GMT

Nice article. As for Neslekkim, manually creating the XML mapping file does require additional manual work. However, this is benificial in a number of cases: Where you don't want your classes littered with attributes, you have existing objects you want to retrofit with LINQ to SQL mappings, and when you need to pass the generated objects to a client that doesn't have 3.5. Using a XML Mapping file makes sense in all of these cases and gives you a completely POCO implementation of the instantiated objects (although not necessarily the object collections if you expose the IQueryable or Table type directly). Along similar lines, I presented the case for using the XML mapping files for POCO support at www.thinqlinq.com/.../LINQ-to-SQL-support-for-POCO.aspx.

re: What If I Don’t Call Dispose() on my LINQ to SQL DataContext Object?

Craig Stuntz — Wed, 20 Aug 2008 19:34:59 GMT

dwhalin,

"typically" means that if (1) the type has a Finalize/"destructor" (usually true if implementing IDisposable; it's part of the pattern) and (2) GC.SuppressFinalize(this) hasn't been called (generally true if you haven't called Dispose) then the instance goes into the finalization queue after it becomes unreferenced.

In other words, it's an implementation detail. You should presume this is the case unless you know otherwise, and even then it could change later.

re: What If I Don’t Call Dispose() on my LINQ to SQL DataContext Object?

dwahlin — Wed, 20 Aug 2008 16:35:53 GMT

Steve,

Paul only says that he believes any IDisposable object should be disposed of properly and that as developers we shouldn't worry about the internal workings of objects like DataContext. Having said that, I fully agree with what he says and will continue to wrap "using" statements around the context object. What Steven points out is interesting to know though but definitely subject to change in future releases.

Craig Stuntz added the following comment to Steven's blog about what happens if an object isn't disposed though which is also interesting. The only thing is...he uses the word "typically" which makes me wonder if this always happens or only in some situations:

"Failing to Dispose an object which implements IDisposable typically results in the object going into the finalization queue (read Chapter 19 of Jeffrey Richter's Applied Microsoft .NET Framework Programming for details). The results of this is that an object's memory that might have otherwise been freed in generation 01 be freed until a later generation collection. If you're creating a lot of these objects, well, do the math."

Either way...I'm still a fan of explicitly disposing of any object that implements IDisposable so it's a moot point for me.

re: What If I Don’t Call Dispose() on my LINQ to SQL DataContext Object?

Steve — Wed, 20 Aug 2008 12:52:56 GMT

I don't think he is right this time. See the comment by Paul Wilson.

I will have to agree here with Paul.

Silverlight 28 Articles from Dan Wahlin « Rich Internet Applications

Silverlight 28 Articles from Dan Wahlin « Rich Internet Applications — Wed, 20 Aug 2008 12:31:21 GMT

Pingback from Silverlight 28 Articles from Dan Wahlin « Rich Internet Applications

2008 August 20 - Links for today « My (almost) Daily Links

2008 August 20 - Links for today « My (almost) Daily Links — Wed, 20 Aug 2008 10:15:51 GMT

Pingback from 2008 August 20 - Links for today « My (almost) Daily Links

2008 August 20 - Links for today « My (almost) Daily Links

2008 August 20 - Links for today « My (almost) Daily Links — Wed, 20 Aug 2008 06:14:29 GMT

Pingback from 2008 August 20 - Links for today « My (almost) Daily Links

funny wallpaper » What If I Don???t Call Dispose() on my LINQ to SQL DataContext Object?

Wed, 20 Aug 2008 06:11:14 GMT

Pingback from funny wallpaper » What If I Don???t Call Dispose() on my LINQ to SQL DataContext Object?