How to dispose a dataset completely

  • Thread starter Thread starter Atul
  • Start date Start date
Oh, i expressed myself badly - it has not much effect besides closing
connection should be better.
Click to expand...

What do you mean by the last part - "should be better"?
Actaully, it does another step that Close doesn't. See below.
Click to expand...

Sure. And it's fine for it to reset the connection string, because
after disposing of it, you won't be using it again (I assume - if you
do you're in trouble).

So, given all the discussion we've had, I don't see any advantage to
using Close over Dispose (the latter of which is easier to use in C#,
with the using statement) unless you want to reopen the connection
using the same object.
 
What do you mean by the last part - "should be better"?
Click to expand...

"it has not much effect besides closing the connection" is a better
statement. Gee, my english.
Sure. And it's fine for it to reset the connection string, because
after disposing of it, you won't be using it again (I assume - if you
do you're in trouble).
Click to expand...

Only unless you don't set connectionstring again. If you do, you can freely
reuse connection IMO even it was disposed.
So, given all the discussion we've had, I don't see any advantage to
using Close over Dispose (the latter of which is easier to use in C#,
with the using statement) unless you want to reopen the connection
using the same object.
Click to expand...

Yes, yes, you are right. Well, at least for SqlConnection class.
Other connection classes might act differently. Heck, even SqlConnection
behaviour might change in future (speculation again).
 
Cor Ligthert said:
Miha,

Before you misunderstand me, about the dataset I was yesterday busy
writing a same answer as Scott and Alvin when I saw that they had done it.
Therefore I did not see a reason anymore for that, than it can looks if we
are atacking you and that is something I surely do not want to do.
Click to expand...

Sure, this is a discussion.
 
Miha,

Angel has often written that the dispose is as well afecting the connection
pool especially with more than 100 connections. In my idea has he told as
well that they did that however have changed that in the newer version..

Cor
 
Can't say, however Dispose is simply calling Close if the connectionstate is
Open and then it resets the connection string.
(at SqlConnection class level)
 
"it has not much effect besides closing the connection" is a better
statement. Gee, my english.
Click to expand...

Right - no problem :)
Only unless you don't set connectionstring again. If you do, you can freely
reuse connection IMO even it was disposed.
Click to expand...

Quite possibly. I personally never reuse anything I've disposed -
usually because I can't, due to the nature of the using statement.
Yes, yes, you are right. Well, at least for SqlConnection class.
Other connection classes might act differently. Heck, even SqlConnection
behaviour might change in future (speculation again).
Click to expand...

I think if it ever changed so that Dispose didn't do all that was
necessary to make unmanaged resources available again, it would be
breaking the IDisposable contract. That's not impossible, of course,
but it would be very bad form :)
 
I think if it ever changed so that Dispose didn't do all that was
necessary to make unmanaged resources available again, it would be
breaking the IDisposable contract. That's not impossible, of course,
but it would be very bad form :)
Click to expand...

Yep - it has to clean everything :-)
 
Miha,
Can't say, however Dispose is simply calling Close if the connectionstate
is Open and then it resets the connection string.
(at SqlConnection class level)
Click to expand...

As I forever thought, but Angel writes as far as I remember me something
like this: "When we where busy with the connection we used the dispose
....... ". Check the thread I gave you and in that as well the message from
me where is a link to an even longer messagethread.

And do than not read my messages or from Marina, however those from Angel.

Cor
 
Exactly Stephen! Which is why I originally said that I wouldn't bother
disposing a Dataset. My last post said that "if" we are talking about data
access objects I would call dispose.

Stephen B. Hahn said:
DataSet is not a Data Access object, it is a disconnected object
containing
various data related collections. DataAdapter, Command and Connection are
Data
Access objects. DataSet does not implement IDisposable directly. It
inherits
it from MarshalByValueComponent. If you use Reflector you can see that
it's
Dispose method does not release unmanaged resources or call. Thus I'd say
call
dispose on a DataSet object is a waste of cycles. Setting the reference
to Null
or letting it go out of scope is not.

Here's Reflectors disassemble of the code, Dispose() calls Dispose(true):

protected virtual void Dispose(bool disposing)
{
if (disposing)
{
lock (this)
{
if ((this.site != null) && (this.site.Container != null))
{
this.site.Container.Remove(this);
}
if (this.events != null)
{
EventHandler handler1 = (EventHandler)
this.events[MarshalByValueComponent.EventDisposed];
if (handler1 != null)
{
handler1(this, EventArgs.Empty);
}
}
}
}
}



Scott M. said:
You've made 2 contradictory statements here:
---------
"I agree. From all that I have read, the only time that you should
implement IDisposable is if you are using unmanaged resources. "

...and...

"Since there is as of yet no data access API that is 100% managed (and
there
will not likely ever be) it is important to dispose all objects that
implement IDisposable."
----------

I would agree that when we are talking about data access classes, calling
Dispose is generally wise. But, not all classes that expose a Dispose
method are data access classes (in fact, the vast majority aren't) and
for
those there may be no need at all in calling Dispose.

Matt Osborne said:
Since there is as of
yet no data access API that is 100% managed (and there will not likely
ever
be) it is important to dispose all objects that implement IDisposable.
We
have had problems in the past with memory leaks that were not resolved
until
we started calling Dispose.

The only caution that I offer with Dispose is that once its called,
there
is
no going back. Make sure that there are not other objects refrencing
the
disposed object as they could cause exceptions if methods or properties
are
called after Dispose is called.

Matt Osborne

"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
How do you know if the class is holding unmanaged resources?
You should call Dispose on every instance to relase resources asap.
Plus, you don't know what the future changes might be.
So, call Dispose on anything that implements IDisposable asap.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
SLODUG - Slovene Developer Users Group
www.rthand.com

You really don't need to bother disposing a DataSet (or any other
.NET
object for that matter) unless the object is holding on to unmanaged
resources that need to be manually cleaned up when you are done
using
the
object. This is the whole point of the Garbage Collector.


Hi,

Once a dataset is populated from DataAdapter, I want to release the
memory acquired by dataSet object. So I call oDataSet.Dispose().
But
it doesnot disposes the internal objects like Datatable/dataColumn.

Should I have to call Dispose() method for these internal objects
explicitely? OR DataSet.Dispose() takes care to clear the internal
objects?

Thanx,
Atul
Click to expand...
Click to expand...
Click to expand...
 
Hi,

DataSet/DataColumn are derived from MarshalByValueComponent &
MarshalByValueComponent has method Dispose() & Finalize(destructor).
So I think its *always* better to call a Dispose() method on these
objects, since Dispose() will suppress the Finalize method... (so
objects(DataSet/DataColumn will be released earlier in GC.)

Is this OK?

-Atul
 
Actually the dataset calls [mscorlib]System.GC::SuppressFinalize(object) in
its constructor.

JD

Atul said:
Hi,

DataSet/DataColumn are derived from MarshalByValueComponent &
MarshalByValueComponent has method Dispose() & Finalize(destructor).
So I think its *always* better to call a Dispose() method on these
objects, since Dispose() will suppress the Finalize method... (so
objects(DataSet/DataColumn will be released earlier in GC.)

Is this OK?

-Atul



Jon Skeet [C# MVP] <[email protected]> wrote in message
Unfortunately, DataSet derives from MarshalByValueComponent, which
brings along IDisposable baggage. I'd call Dispose on it if I were
remoting it, or marshalling it across AppDomain boundaries, but I
wouldn't bother otherwise.

In general though, I agree with you - unless I've taken a close look at
why something implements IDisposable and decided that it's a red
herring in the case I'm using, I call Dispose on it.
Click to expand...
Click to expand...
 
Hi,
just to check

Stephen B. Hahn said:
DataSet is not a Data Access object, it is a disconnected object containing
various data related collections. DataAdapter, Command and Connection are Data
Access objects. DataSet does not implement IDisposable directly. It inherits
it from MarshalByValueComponent. If you use Reflector you can see that it's
Dispose method does not release unmanaged resources or call. Thus I'd say call
dispose on a DataSet object is a waste of cycles. Setting the reference to Null
or letting it go out of scope is not.

Here's Reflectors disassemble of the code, Dispose() calls Dispose(true):

protected virtual void Dispose(bool disposing)
{
if (disposing)
{
lock (this)
{
if ((this.site != null) && (this.site.Container != null))
{
this.site.Container.Remove(this);
}
if (this.events != null)
{
EventHandler handler1 = (EventHandler)
this.events[MarshalByValueComponent.EventDisposed];
if (handler1 != null)
{
handler1(this, EventArgs.Empty);
}
}
}
}
}



Scott M. said:
You've made 2 contradictory statements here:
---------
"I agree. From all that I have read, the only time that you should
implement IDisposable is if you are using unmanaged resources. "

...and...

"Since there is as of yet no data access API that is 100% managed (and there
will not likely ever be) it is important to dispose all objects that
implement IDisposable."
----------

I would agree that when we are talking about data access classes, calling
Dispose is generally wise. But, not all classes that expose a Dispose
method are data access classes (in fact, the vast majority aren't) and for
those there may be no need at all in calling Dispose.

Matt Osborne said:
Since there is as of
yet no data access API that is 100% managed (and there will not likely
ever
be) it is important to dispose all objects that implement IDisposable. We
have had problems in the past with memory leaks that were not resolved
until
we started calling Dispose.

The only caution that I offer with Dispose is that once its called, there
is
no going back. Make sure that there are not other objects refrencing the
disposed object as they could cause exceptions if methods or properties
are
called after Dispose is called.

Matt Osborne

"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
How do you know if the class is holding unmanaged resources?
You should call Dispose on every instance to relase resources asap.
Plus, you don't know what the future changes might be.
So, call Dispose on anything that implements IDisposable asap.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
SLODUG - Slovene Developer Users Group
www.rthand.com

You really don't need to bother disposing a DataSet (or any other .NET
object for that matter) unless the object is holding on to unmanaged
resources that need to be manually cleaned up when you are done using the
object. This is the whole point of the Garbage Collector.


Hi,

Once a dataset is populated from DataAdapter, I want to release the
memory acquired by dataSet object. So I call oDataSet.Dispose(). But
it doesnot disposes the internal objects like Datatable/dataColumn.

Should I have to call Dispose() method for these internal objects
explicitely? OR DataSet.Dispose() takes care to clear the internal
objects?

Thanx,
Atul
Click to expand...
Click to expand...
Click to expand...
 
Back
Top