Do I really need to dispose of all DataTables?

  • Thread starter Thread starter David Smith
  • Start date Start date
D

David Smith

Pretty straight forward question, right? I'm asking because this is one of
the recommendations I'm getting from VSTS code analysis.

My problem is that I have a pattern of code sprinkled throughout much of
my business layer where data access code calls static methods that, in turn,
call stored procedures that read the selected data into newly created DataTables
and return these tables. It might be difficult to track and dispose of all
these tables.

So, how leaky are undisposed of DataTables?
 
Currently you probably don't need to.
However, it is recommended that you dispose everything that implements
IDisposable.
 
David,
So, how leaky are undisposed of DataTables?
You don't have to dispose anything that has no unmanaged resource.

AFAIK are there in ADONET no unmanaged resources involved

The purpose of managed code is to do the releasing for you at the best
moment.

Cor
 
But we're told to always Dispose of connections, so there must be some unmanaged
resources involved. I create all connections in "using" blocks. DataTables,
on the other hand, are often returned from methods, passed in as parameters,
real-bound to grids, and fake bound to trees (fake because there is no databinding,
just looping over the table and creating nodes)
 
I would say that is really a matter of debate. In fact, there have been a
lot of debates over whether or not connections really need to be disposed,
or if just closing is enough. So I don't think you can state this as a
matter of fact.
 
No you don't. I think DataTable constructor have GC.SuppressFinalize(this)
anyway .. (I think .. I could be wrong).
Obviously don't keep 'em around eatin' memory.

- SM
 
David said:
Pretty straight forward question, right? I'm asking because this is
one of the recommendations I'm getting from VSTS code analysis.

My problem is that I have a pattern of code sprinkled throughout much
of my business layer where data access code calls static methods
that, in turn, call stored procedures that read the selected data
into newly created DataTables and return these tables. It might be
difficult to track and dispose of all these tables.

So, how leaky are undisposed of DataTables?

Well, they seem to stay around for quite a while. Just try to
implement calling dispose on a couple of them which are used very
frequently. My tests show that the memory footprint of a large asp.net
application was much lower after I did that (and I used the datatables
in the same way as you do: call a DAL class, that one creates a
datatable, the returned datatable is bound to a repeater etc.). Which
was strange, because the Dispose method in a datatable didn't do much.

It's often impossible to call Dispose on all your data-access code, at
least in some situations.

Do some profiling with the performance monitor of windows and teh .NET
CLR counters available to you and see if it makes a difference, I saw
big differences, but it could be related to the databinding scenario I
used, as binding a datatable to a repeater creates a dataview under the
hood.

FB

--
 
Marina said:
I would say that is really a matter of debate. In fact, there have
been a lot of debates over whether or not connections really need to
be disposed, or if just closing is enough. So I don't think you can
state this as a matter of fact.

There's no standard, especially for data-access related components.
SqlClient's SqlConnection.Dispose for example also takes care of the
associated SqlCommand objects (which don't need dispose really).

Oracle's ODP.NET doesn't do that: OracleConnection.Dispose doesn't
clean up OracleCommand objects associated with the connection. More
importantly: OracleParameter has a Dispose method as well, which IS
required.

I can see optimization paths if you see Dispose and Close as 2
different things: Close can mean: no longer needed, but keep the
resources around so when I open the connection again, they're available
for me. If Close means Dispose, those resources are gone and the
connection Open will be slower. This is all low-level stuff, but in
some scenario's it might be more efficient to use close instead of
dispose, IF the client supports different behavior of course.

FB


--
 
Frans,
Well, they seem to stay around for quite a while. Just try to
implement calling dispose on a couple of them which are used very
frequently. My tests show that the memory footprint of a large asp.net
application was much lower after I did that

IMHO is that not direct an advantage.

It is an advantage as a system keeps as much handles and memory available as
is needed for the processing.

If with keeping (while not needed) the memory low any processing time is
spent, than it is for me even a disadvantage.

However as said, just my opinion.

Cor
 
Back
Top