A
ad
What is the difference between connection.Dispose() and connection.Close()?
W
William \(Bill\) Vaughn
Dispose calls Close and marks the object for destruction so it can't be
reopened.
Close releases the Connection back to the pool.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
reopened.
Close releases the Connection back to the pool.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
F
flipdoubt
Hello William,
What about the using construct? Is it equivalent to Dispose or Close? Does
this not send the connection back to the pool?
using( SqlConnection conn = new SqlConnection( connString ) )
{
What about the using construct? Is it equivalent to Dispose or Close? Does
this not send the connection back to the pool?
using( SqlConnection conn = new SqlConnection( connString ) )
{
S
Sahil Malik [MVP]
Flip,
At the end of the using block, dispose is called for you - which will close
the connection (and do some more clean up work). Because dispose calls
close, it will release the underlying physical connection back to the
connection pool. .. so to make the long story short - the code snippet below
will send the connection back to the pool.
Here is some interesting reading on it if you wish to read further on how
dispose works, close works, and how does connection pooling work under the
scenes.
http://codebetter.com/blogs/sahil.malik/archive/2004/11/12/31798.aspx
- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
At the end of the using block, dispose is called for you - which will close
the connection (and do some more clean up work). Because dispose calls
close, it will release the underlying physical connection back to the
connection pool. .. so to make the long story short - the code snippet below
will send the connection back to the pool.
Here is some interesting reading on it if you wish to read further on how
dispose works, close works, and how does connection pooling work under the
scenes.
http://codebetter.com/blogs/sahil.malik/archive/2004/11/12/31798.aspx
- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
S
Sahil Malik [MVP]
Not really. Dispose does not mark anything for destruction.
Dispose is just another method that by convention is supposed to do the
object's clean up work.
- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
Dispose is just another method that by convention is supposed to do the
object's clean up work.
- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
C
Cor Ligthert
Bill,
I read this so often written in general as bellow (Not only by you I have
done it as well).
It gives the idea that this is for all databases.
Is this standard true, by instance for Access.
Before you think that this is a trick question. My knowledge is as a user
(programs) from a database, not as a database administrator. Therefore I
know what pooling does, however not in depth in the implementation.
Cor
I read this so often written in general as bellow (Not only by you I have
done it as well).
It gives the idea that this is for all databases.
Is this standard true, by instance for Access.
Before you think that this is a trick question. My knowledge is as a user
(programs) from a database, not as a database administrator. Therefore I
know what pooling does, however not in depth in the implementation.
Cor
C
Cor Ligthert
Bill,
now very much involved in 2.0. In 1.x the Dispose is in my idea overloaded
to give the internal connectionstring back to the pool while the close does
not do that.
Another point is that at least in 1.x a disposed connection needs to be new
created, while a closed can just be reopened.
Cor
AFAIK is there is a difference between 1.x and 2.0 in using dispose. You are
now very much involved in 2.0. In 1.x the Dispose is in my idea overloaded
to give the internal connectionstring back to the pool while the close does
not do that.
Another point is that at least in 1.x a disposed connection needs to be new
created, while a closed can just be reopened.
Cor
C
Cor Ligthert
Bill,
And to deny again what I wrote, I had very deep knowledge about the first
Forte databases. Maybe you knew/know them. Those were in my opinion
excelent.
Cor
And to deny again what I wrote, I had very deep knowledge about the first
Forte databases. Maybe you knew/know them. Those were in my opinion
excelent.
Cor
W
William \(Bill\) Vaughn
Yes, I was wrong about Dispose, it does not mark the object for destruction
but it does clear the properties so you'll have to reset properties like the
ConnectionString before its reuse.
As far as pooling behavior, Dispose and Close both return the Connection to
the pool for reuse. Each of the .NET providers implements a Connection
pool--it's part of the core functionality.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
but it does clear the properties so you'll have to reset properties like the
ConnectionString before its reuse.
As far as pooling behavior, Dispose and Close both return the Connection to
the pool for reuse. Each of the .NET providers implements a Connection
pool--it's part of the core functionality.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
C
Cor Ligthert
Bill,
the Connection Pool, for whom, after that I advised to change the close for
dispose (according to the messages from Angel), the Connection pool problems
were gone?
Cor
Why were there than so many people in these newsgroup, who had problems with
the Connection Pool, for whom, after that I advised to change the close for
dispose (according to the messages from Angel), the Connection pool problems
were gone?
Cor
S
Sahil Malik [MVP]
Thats why I like you so much. Damn intelligent and willing to admit where
you are incorrect. Why can't we find more people like Bill Vaughn.
- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
you are incorrect. Why can't we find more people like Bill Vaughn.
- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
S
Sahil Malik [MVP]
<beyondanydoubt>Close will return the underlying physical connection to the
connection pool.</beyondanydoubt>
No clue what Angel was saying - can you point to some written text from him?
- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
connection pool.</beyondanydoubt>
No clue what Angel was saying - can you point to some written text from him?
- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
W
William \(Bill\) Vaughn
Sourcery? Dispose and Close both return the connection to the pool. If they
were calling neither or the logic let the PSP sneak away without calling one
or the other, adding Dispose would do the trick--assuming it's actually
called. I've seen lots of cases where developers pass a DataReader to
another routine that fails to close the DataReader (assuming they remembered
to use the correct CommandBehavior). I've seen situations where the Close
(or Dispose) is there, but the logic bypasses it if there is an exception
(the Close is not in the Finally).
Unless it's a bug (which I doubt), I don't expect that Dispose will cure any
more connection pool issues than Close. Is there a code example somewhere
that shows that Dispose works where Close does not? If so, I know a number
of folks on campus that would love to see it.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
www.sqlreportingservices.net
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
were calling neither or the logic let the PSP sneak away without calling one
or the other, adding Dispose would do the trick--assuming it's actually
called. I've seen lots of cases where developers pass a DataReader to
another routine that fails to close the DataReader (assuming they remembered
to use the correct CommandBehavior). I've seen situations where the Close
(or Dispose) is there, but the logic bypasses it if there is an exception
(the Close is not in the Finally).
Unless it's a bug (which I doubt), I don't expect that Dispose will cure any
more connection pool issues than Close. Is there a code example somewhere
that shows that Dispose works where Close does not? If so, I know a number
of folks on campus that would love to see it.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
www.sqlreportingservices.net
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
S
Sahil Malik [MVP]
Regards connection pooling, I doubt there is a differnce between dispose and
close. All you have to do is look at the reflected code, dispose calls
close - KAPUT !! (and does a little bit more which has nothing to do with
pooling).
- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
close. All you have to do is look at the reflected code, dispose calls
close - KAPUT !! (and does a little bit more which has nothing to do with
pooling).
- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
W
William \(Bill\) Vaughn
KAPUT? As in the German word that means "broken"? Do you mean "Wala!"?
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
www.sqlreportingservices.net
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
www.sqlreportingservices.net
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
S
Sahil Malik [MVP]
I thought Kaput meant finish i.e. end of story. .. i.e. made my point, thats
it beyond any doubt.
- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
it beyond any doubt.
- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
C
Cor Ligthert
Bill,
I think that searching on Google where my misunderstanding comes from.
Marina and I are writing already for a very long time in these newsgroups
that calling dispose, in situations where that exist because of that it is
inheriting from component (which implements Idisposable), is mostly culprit.
Angel gave more times reactions on those messages (as far as I remember me)
and told than that it was absolute necessary to use dispose for the
connectionpooling. I see now that in messages from him that close and
dispose are for him (reading them exact) the same. Probably was that the
reason that I got a complete wrong idea because these messages came forever
when I wrote about dispose.
Before that time, I wrote forever in other replies that it is better to use
the close (it gives at least nicer maintainable programs). However, that
replies where never related to dispose.
It is not impossible that in those situations were I advised people to use
dispose when there where connectionpool problems, that there was no closing
from connections at all.
I will be glad if you are right, (what I suppose now) because than there
will again a Dispose myth be gone.
Cor
I think that searching on Google where my misunderstanding comes from.
Marina and I are writing already for a very long time in these newsgroups
that calling dispose, in situations where that exist because of that it is
inheriting from component (which implements Idisposable), is mostly culprit.
Angel gave more times reactions on those messages (as far as I remember me)
and told than that it was absolute necessary to use dispose for the
connectionpooling. I see now that in messages from him that close and
dispose are for him (reading them exact) the same. Probably was that the
reason that I got a complete wrong idea because these messages came forever
when I wrote about dispose.
Before that time, I wrote forever in other replies that it is better to use
the close (it gives at least nicer maintainable programs). However, that
replies where never related to dispose.
It is not impossible that in those situations were I advised people to use
dispose when there where connectionpool problems, that there was no closing
from connections at all.
I will be glad if you are right, (what I suppose now) because than there
will again a Dispose myth be gone.
Cor