Dispose vs Close

  • Thread starter Thread starter Robert Strickland
  • Start date Start date
R

Robert Strickland

Trying to determine if calling Dispose destroys the connection instead of
releasing the connection back to the connection pool where a close does
release to the connection pool. I have read documentation that made that
statement. Most everyone agrees dispose does call close then cleans up some
more. But does Dispose destroy the connection and not release back to the
pool (when connection pooling is enabled)?

Also, does a data layer have to implement the IDisposable interface when
working with connections (closing and releasing a connection) in the
component? Our apps do create and pass in a connection when working with
transactions but for the selects we use the datareader with the
CloseConnection behavior and some datasets with the disconnection taking
place.

And one more item, we have encrypted connection strings in our web.config
file. Is using connection factories better and is there any explaination on
how to build the factory?

Thanks
 
Hi,

dispose releases the resources held by the connection. I think instead of
returning back the connection to the pool (with pooling enabled), it
destroys it.

you should consider implementing IDisposable in your DAL classes when you
are using unmanaged resources like file handlers, COM classes etc so that
you can dispose them in a more structured way.

Thanks
Joyjit
 
Dispose does call Close, but only extra cleanup it does is that it sets
connection string to null, then calls base class's Dispose (Component) which
does the cleanup for component related stuff like removing component from
its container which then have nothing to do with dabase connection specific
resources

Answer is that no, Dispose does not destroy the connection either, only
thing that destroys something in .NET is garbage collector (GC).
 
Long message but plenty of good reading stuff -----

Either close, or dispose (by virtue of calling close) would make the
connection available for connectionpooling, provided you haven't disabled
connectionpooling otherwise. And yes it is true that Dispose does more than
Close - (more on this below).

Definition of "Dispose" ---
Use this method to close or release unmanaged resources such as files,
streams, and handles held by an instance of the class that implements this
interface. This method is, by convention, used for all tasks associated with
freeing resources held by an object, or preparing an object for reuse.
...... All it does is - as stated above - releases resources - which is
simply calling close and a bit else as shown below in
SqlConnection.Dispose(Boolean) code ---

protected override void Dispose(bool disposing)
{
if (disposing)
{
switch (this._objectState)
{
case ConnectionState.Open:
{
this.Close();
break;
}
}
this._constr = null;
}
base.Dispose(disposing);
}

The extra work other than simply closing that dispose did above was ----- it
set _constr to null - which is an instance of an internal sealed class
called "SqlConnectionString : DBConnectionString". That class has tonnes of
static and const shyt in it - it is huge with an ugly vtable - I am sure
they must have a reason to do all that, but dude that class is big ugly and
expensive - therefore it made logical sense to set it to "null" so GC could
merrily come by and swoosh it next time around it's doin' it's thing.

Does your datalayer (or any object for that matter) have to implement
dispose? Just as above - ask yourself this question - "Is my datalayer
holding expensive objects?". Remember, dispose is nothing funkier than
calling a method, and it is just as good as the Dispose's implementation.
Not to mention - it does take some time to call Dispose, and if all you are
doing is setting an integer to "0", then it might not make sense to have
that extra code/complexity/call/confusion (cccc). What I generally do is
this --
http://dotnetjunkies.com/WebLog/sahilmalik/archive/2004/05/19/14019.aspx

Instead of passing Connection Objects - consider passing connectionstrings
and creating connection objects. (For various reasons).

ConnectionFactory? I take it that is similar to ClassFactory - basically you
should abstract connection building into one function in the one class -
that is the base class of your data access layer. That is a pattern I have
used, and I am sure other patterns might exist too.

To answer your last question - and it is amazing how many folks are
surprised to hear this -
But does Dispose destroy the connection and not release back to the
pool (when connection pooling is enabled)?
Click to expand...

Dispose - as mentioned above is nothing funkier than calling a method - that
does what you saw above. It *does* release and make the connection available
for connection pooling. The trick to remember over here is - you are
thinking too complicated - the actual SqlConnection object is not the object
that is pooled - if that were the case, you'd be pooling that yourself
through enterprise services or something like that - Microsoft made it easy
for you - by implementing an internal sealed class called
"SqlConnectionPoolManager", and everytime you call "Open" - and as long as
the CONNECTIONSTRING - is *exactly* the same .... connection pooling is
automatically taken care of by calling
SqlConnectionPoolManager.GetPooledConnection. So all you do is call
Connection.Open - and pooling happens AUTOMAGICALLY !! WHOAAAA !! :-)))))

Fantastic stuff huh? :-)

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik
 
Robert,

When it is about Dispose vs Close often Angel jumps in.

Here some messages in a threads with him and from him
http://tinyurl.com/5lucm

Angel has written this moreoften in detail in this newsgroup. When you read
the documentation you should think it is only releasing the connectionstring
from the object that does the dispose more. However when you read Angels
messages than there should be more under the hood.

He gives this advise especially with more than 100 connections.

I hope this gives some ideas?

Cor
 
Back
Top