Which data objects to dispose

  • Thread starter Thread starter murphy
  • Start date Start date
M

murphy

We are having a memory leak issue and looking at possible causes. Do
datasets and datatables need to be explicitly disposed? My
understanding is that this is only required with connections and
datareaders. In fact doing so on a dataset could be a problem if it is
in use remotely (not an issue for us). I've heard that if a class
implements IDisposable that it means that one must explicitly dispose
of its instances but I'm dubious.

Thanks!
 
Murphy,

In pure managed *and* stateless code, nothing needs to be disposed, though
it is better to be disposed.

Dispose is nothing but a method on the object, and it's only as good as the
object implemented it. So if the author of the object did implement dispose,
you would be wise to call it, especially when dealing with pooled objects
like Connections.

In a remoting/distributed scenario it gets a bit more complex; but thats
another story.

However, memory leaks can still be caused even in managed code. Typically
when you have stateful objects, which end up accruing each other's instances
over multiple calls.

There is a tool called CLRProfiler, run your app thru that, and you'd know
what objects are the biggest pigs in a neat graphical manner. Also the
latest MSDN Mag talks about such stuff in an article called "memory lane".

Enjoy.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik
 
Hi murphy,
We are having a memory leak issue and looking at possible causes. Do
datasets and datatables need to be explicitly disposed? My
understanding is that this is only required with connections and
datareaders. In fact doing so on a dataset could be a problem if it is
in use remotely (not an issue for us). I've heard that if a class
implements IDisposable that it means that one must explicitly dispose
of its instances but I'm dubious.
Click to expand...

Sahil explained it well.
You should dispose it explicitly if the class implements IDispose as this is
a best practice.
Sometimes the class does nothing within Dispose but even this can change in
the future.
Bottom line: Always dispose if there is IDispose.Dispose.
If you suffer memory leaks (btw, how do you know?) you should really use a
profiler to pinpoint the cause.
There are a lot of profilers out there, such as AutomatedQA's AQtime:
http://www.automatedqa.com/techpapers/net_allocation_profiler.asp
 
Thanks to both of you for your detailed replies. Be assured we are
disposing of Connections and DataReaders where used. I'm being a bit
balky here about finding out I have to write code for something I
thought was automatic ;-)

If a class such as DataSet implements IDispose, can we infer that not
calling Dispose will allow memory to leak? I'm a little concerned
about trying to follow what is being called best practice because:

1) I don't find mention in MSDN of DataSet and DataTable posing leak
potential or that calling dispose is best practice. Some examples show
it called, many do not.
2) I've read that dispose should not be called in a distributed
scenario (not our case at the moment)
3) I've read that disposing of DataSet does not cause elements of the
DataSet, such as the DataTables to be disposed. Code to completely
dispose of DataSets will therefore be quite verbose.
 
Back
Top