Disposing of a DataSet

Seems everyone I ask about this Subject I get a Different Answer so I want to post it here too.

If the DataSet is a Managed object is there any benifit to calling Dispose on it.  It seems even though you call dispose on the DataSet you are still able to access it. 

Yes I know to you should call the objects Dispose Method if it Implements IDisposable but in the DataSets case it only Inherits the Dispose method from MarshalByValueComponenet which Implements IDisposable.

In my opinion I don't think it is necessary to call a Dataset Dispose method since it will not do anything with the dataset anyways.  But I would like to hear what anyone else has to say on the matter.

Ryan

In theory:
If an object implements Close or Dispose, it does so because it holds an expensive, shared, native resource that should be released as soon as possible.

In real life:
I do agree with you that DataSet.Dispose does nothing and is just a side effect of inheritance.
 
As for me I never call Dispose on a DataSet.

It's always best to clean up your own garbage. Use the "using" statement, then it will do it for you:

using(DataSet MyDataSet = new DataSet())
{
   ....
}

I know I can use the using statement with a dataset only for the fact that it inherited a dispose method from MarshalValueByComponent but what is the point if it does not dispose my dataset and I can continue useing my dataset after I dispose of it.

R.

Crazi_Ivan wrote:

I know I can use the using statement with a dataset only for the fact that it inherited a dispose method from MarshalValueByComponent but what is the point if it does not dispose my dataset and I can continue useing my dataset after I dispose of it.

It calls Dispose... it's just that Dispose doesn't (yet) do anything.

One point is that Microsoft could change the implementation of DataSet to something that needs to be non-trivially disposed, and your code wouldn't break.

Calling Dispose just lets the garbage collector know that you are done with the object so feel free to clean it up in its next pass.  So really dispose is more of a flag than a method to free up objects.

If you want to get rid of an object that is hogging up a lot of resources you could always call Dispose then follow that with GC.Collect() to force the garbage collector to make a pass.

blowdart wrote:

JeremyJ wrote: Calling Dispose just lets the garbage collector know that you are done with the object so feel free to clean it up in its next pass.  So really dispose is more of a flag than a method to free up objects.

Oh no it's not.

Dispose is whatever the object developer wants it to be, but by convention it's supposed to free unmanaged resources immediatly on call.

What it is not is just a flag for the gc.

Yes that is true if the person is implementing their own Dispose method.  I was referring to objects that already have a Dispose method implemented. 

JeremyJ wrote:

If you want to get rid of an object that is hogging up a lot of resources you could always call Dispose then follow that with GC.Collect() to force the garbage collector to make a pass.

a) If you want to responsibly manage resoures in use by your application you should dispose disposable objects when you are done with them.
b) As a rule, you should almost never call GC.Collect().

JeremyJ wrote:

blowdart wrote: JeremyJ wrote: Calling Dispose just lets the garbage collector know that you are done with the object so feel free to clean it up in its next pass.  So really dispose is more of a flag than a method to free up objects. Oh no it's not. Dispose is whatever the object developer wants it to be, but by convention it's supposed to free unmanaged resources immediatly on call. What it is not is just a flag for the gc.

Yes that is true if the person is implementing their own Dispose method.  I was referring to objects that already have a Dispose method implemented. 

No. The semantics of IDisposable don't change based on who implements that type. If you want to responsibly manage resoures in use by your application you should dispose disposable objects when you are done with them.

I was mistaken about the flag.  It is not flagged on Dispose but it is flagged when the dataset goes out of scope.  Datasets are managed objects and Dispose does nothing.  What I mean by flag is that the garbage collector makes a pass and sees the object as unreachable and moves it to the next level of garbage collection.

This article can explain it better than I can:
http://http://msdn.microsoft.com/msdnmag/issues/1200/gci2/">http://msdn.microsoft.com/msdnmag/issues/1200/gci2/">http://http://msdn.microsoft.com/msdnmag/issues/1200/gci2/

Yes it is true that you should avoid calling GC.Collect().  I was just mentioning it as an example of a way that you can force garbage collection if you needed to.

blowdart wrote:

    OK but datasets are rare in that regard, they have Dispose because of their inheritence tree. The comment that if dispose is there you should call it as soon as you can still stands.

    Implementing dispose pattern is just an explicit way to release the unmanaged resources, if you managed object such as DataSet object doesn't wrap any unmanaged resources, why do you need to write redundant code to call it's dispose method?

Sheva

JeremyJ wrote:

Calling Dispose just lets the garbage collector know that you are done with the object so feel free to clean it up in its next pass.  So really dispose is more of a flag than a method to free up objects.

If you want to get rid of an object that is hogging up a lot of resources you could always call Dispose then follow that with GC.Collect() to force the garbage collector to make a pass.

I think you are making a quite false statement. there is only two ways in .NET that can cleaning up the unmanaged resources. one is to implement your clean-up logic in the Finalize method, and another way is to do it in the Dispose method by have you wrapper classes implementing the IDisposable interface. Finalize method is quite useful because it can ensure that the unmanaged resources aren't leaked when managed objects have their memory reclaimed, because the garbage collector will always call this method if the targeting object have this method defined in its method pointer table. but the problem with Finalize method is that although garbage collector will definitely call this method, but this calling process is indeterministic, which means that you have no guarantee when it will be called. and because it isn't a public method, a comsumer of the class cannot call it explicitly. so the alternative way to implement the clean-up logic became quite straightforward, Dispose method just give the consumer of your class the capability to deterministically clean up the unmanaged resources. when you have the Dispose method called, you have the guarantee that the unmanaged resources do get cleaned. and one typical implementation of this class is to call GC.SuppressFinalize(this) method to prevent garbage collector to put the object into the finalization list, which in turn prevents the Finalize method get called. for more information about the Garbage collection mechanism and how to implement the dispose pattern, please refer to Jeffrey Richter's awesome must read book: Applied Microsoft .NET Framework programming, chapter 19 "Automatic Memory Management(Garbage Collection)".

Sheva

And where could I find the best practice you mentioned above?

Sheva

blowdart wrote:

    Well they're certainly in the internal ones work uses. One thing to remember is the GC will not call dispose, so if there are managed resources you'd better hope the object finaliser will work out they're still there and "dispose" of them.

    Please try your best not to implement class destrcutor method, and that's the best practice Jeffrey Richter recommends in his book Applied Microsoft.NET Framework programming. and he also sheds light on when to use using statement and when not to use it.

blowdart wrote:

I really fail to see why you're so resistant to this.

    Just give me more arguments to convince me, and I think one argument you have made is really witty:
    2) You can't rely on DataSets staying the same, and Dispose doing little or nothing.

Sheva