Question about IDispose

[Alvin Bruney [MVP]]

with the using construct, exit from scope calls dispose on said object. But
what happens in a connection pooling scenario? Is the run-time smart enough
to realize that Object Pooling is being used so it will not call dispose and
instead flag the object similar to what close() does when pooling is in
effect. Or does it really go ahead and shut down the object? If it does,
then isn't it circumventing the object pooling? Does anybody know?

I ask because I often use the using construct instead of calling close, but
I wonder if I am introducing expense into the equation if the dispose is not
behaving efficiently like I assumed.

??

 

[Daniel O'Connell [C# MVP]]

with the using construct, exit from scope calls dispose on said object.
But
what happens in a connection pooling scenario? Is the run-time smart
enough
to realize that Object Pooling is being used so it will not call dispose
and
instead flag the object similar to what close() does when pooling is in
effect. Or does it really go ahead and shut down the object? If it does,
then isn't it circumventing the object pooling? Does anybody know?

I ask because I often use the using construct instead of calling close,
but
I wonder if I am introducing expense into the equation if the dispose is
not
behaving efficiently like I assumed.

Using should blindly call Dispose. It would be up to the object implementer
to write a Dispose method that works properly with the pooling system. You
will have to analyze the behaviour of the class in question.

??

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b

 

[Alvin Bruney [MVP]]

so what exactly is the point of this in a web page (windows forms doesn't
care about pooling for the most part because it is not inherently
expensive).
using(MySQLConnection cn = new MySQLConnection (Global._connString3))

{

}

I am not in agreement with this implementation at all. Because it is
inherently costly at the expense of being safe. Is it an either safety or
performance cake? That totally negates the benefit of connection pooling. It
should come with a disclaimer as well because I always assumed it worked
with some sort of intelligence.

Give me a good reason why dispose should not have some built-in intelligence
with regard to object pooling. I need this intelligence for web development
because object creation is inherently expensive. It doesn't matter for
windows program. I suspuct web program was an after thought. This is wrong
in my limited view of what is happening.


--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b

with the using construct, exit from scope calls dispose on said object.
But
what happens in a connection pooling scenario? Is the run-time smart
enough
to realize that Object Pooling is being used so it will not call dispose
and
instead flag the object similar to what close() does when pooling is in
effect. Or does it really go ahead and shut down the object? If it does,
then isn't it circumventing the object pooling? Does anybody know?

I ask because I often use the using construct instead of calling close,
but
I wonder if I am introducing expense into the equation if the dispose is
not
behaving efficiently like I assumed.

Using should blindly call Dispose. It would be up to the object implementer
to write a Dispose method that works properly with the pooling system. You
will have to analyze the behaviour of the class in question.

??

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b

 

[Jon Skeet [C# MVP]]

so what exactly is the point of this in a web page (windows forms doesn't
care about pooling for the most part because it is not inherently
expensive).
using(MySQLConnection cn = new MySQLConnection (Global._connString3))

{

}

I am not in agreement with this implementation at all. Because it is
inherently costly at the expense of being safe. Is it an either safety or
performance cake? That totally negates the benefit of connection pooling. It
should come with a disclaimer as well because I always assumed it worked
with some sort of intelligence.

Give me a good reason why dispose should not have some built-in intelligence
with regard to object pooling.

Because IDisposable is a very general interface, and shouldn't refer to
anything specific. It's a horrible, horrible idea for something as
general as IDisposable to know about databases - it's putting knowledge
in entirely the wrong place.

The *right* place for the "smarts" is in MySQLConnection, which can
implement IDisposable however it wishes.

I need this intelligence for web development
because object creation is inherently expensive. It doesn't matter for
windows program. I suspuct web program was an after thought. This is wrong
in my limited view of what is happening.

Are you *sure* that using the above pattern is actually ignoring
connection pooling? Don't assume that there's a direct correlation
between MySQLConnection instances and actual connections to the
database.

 

[Daniel O'Connell [C# MVP]]

so what exactly is the point of this in a web page (windows forms doesn't
care about pooling for the most part because it is not inherently
expensive).
using(MySQLConnection cn = new MySQLConnection (Global._connString3))

{

}

I am not in agreement with this implementation at all. Because it is
inherently costly at the expense of being safe. Is it an either safety or
performance cake? That totally negates the benefit of connection pooling.
It
should come with a disclaimer as well because I always assumed it worked
with some sort of intelligence.

Why would you assume that? connection\object pooling is a feature of a
library that should(usually) be transparent to user and language. There is
*nothing* in the language that supports or detracts from the feature.

Give me a good reason why dispose should not have some built-in
intelligence
with regard to object pooling. I need this intelligence for web
development
because object creation is inherently expensive. It doesn't matter for
windows program. I suspuct web program was an after thought. This is wrong
in my limited view of what is happening.

The primary reason is that there is no reason to be. It is the duty of the
implementer of the object to implement pooling in their class. All versions
of the MS provided connection objects appear to achieve the same basic
results no matter if dispose or close is called. How the pooling of the
actual connection works internally shouldn't be destroyed with the dispose
call(perhaps using reference counts or something, thats irrelevent).

Can you give a good reason why intelligence should be there? Why the
changes, for example additional attributes being defined, additional logic
in using(emitting code to check for the attributes on overloads, etc) would
make sense? Considering the actual amount of code needed and the fact it
would probably be performance impairing(calling reflection to check for the
attribute to determine if it participates in a pool, determining how to
dispose the object, etc). Simply writing Dispose so that it allows pooling
to operate makes far more sense. One would hope the MySqlConnection class
actually does this, if not its an issue with the library you are using, not
the language itself.

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b

with the using construct, exit from scope calls dispose on said object.
But
what happens in a connection pooling scenario? Is the run-time smart
enough
to realize that Object Pooling is being used so it will not call
dispose
and
instead flag the object similar to what close() does when pooling is in
effect. Or does it really go ahead and shut down the object? If it
does,
then isn't it circumventing the object pooling? Does anybody know?

I ask because I often use the using construct instead of calling close,
but
I wonder if I am introducing expense into the equation if the dispose
is
not
behaving efficiently like I assumed.

Using should blindly call Dispose. It would be up to the object implementer
to write a Dispose method that works properly with the pooling system.
You
will have to analyze the behaviour of the class in question.

??

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b

 

[Alvin Bruney [MVP]]

Probably I was misunderstood. I'll restate for clarity.



Implementing the using construct disposes of the object in question. The
connection pool is specifically setup to prevent object destruction because
it is inherently expensive to create this object. It is much more efficient
to reuse the object instead of destroying it.

This behavior poses no problem in a windows environment because connections
are cheap, however, the reverse is true in a web environment.



Should the dispose pattern be smart enough to detect pooling? After thinking
about it, Jon is right. Because of how the finalizer works, it is faulty to
place dependency in the overridden dispose function. So it cannot check for
a connection pool flag before destroying the object, at least based on
microsoft's best practices. So the *fix cannot come from the Dispose layer.



Should the fix be implemented at a higher level such as the connection
object layer? After thinking about it, I don't think so for the same reason;
it forces the connection object into knowing more than it is supposed to
about the environment in which it is run. But this doesn't solve the
problem. The problem still remains that the benefits of the pool are being
negated. Why is this important? Consider a high volume website fielding
20000 hits per day. The benefits of pooling here make or break the website.
Negating these benefits is simply not acceptable and must be avoided. But
how can I avoid it if I don't know the negative effects?



What I am suggesting is that Microsoft append a qualifying comment to the
dispose pattern literature indicating that the using construct which
implements the IDispose pattern not be used in combination with object
pooling for web applications because the benefits of pooling may be
negatively affected. With that recommendation in the literature, I can
safely avoid the using construct at a high level and choose to manually
close my objects guaranteeing that the connection pool benefits remain in
effect since calling close() only flags the object for reuse anyway.

Are you *sure* that using the above pattern is actually ignoring

connection pooling?



No, I am not 100%sure. But based on the literature, I make an educated guess
that it ignores pooling because the dispose implementation must make no
assumptions about the environment.

 

[mikeb]

Probably I was misunderstood. I'll restate for clarity.



Implementing the using construct disposes of the object in question. The
connection pool is specifically setup to prevent object destruction because
it is inherently expensive to create this object. It is much more efficient
to reuse the object instead of destroying it.

This behavior poses no problem in a windows environment because connections
are cheap, however, the reverse is true in a web environment.



Should the dispose pattern be smart enough to detect pooling? After thinking
about it, Jon is right. Because of how the finalizer works, it is faulty to
place dependency in the overridden dispose function. So it cannot check for
a connection pool flag before destroying the object, at least based on
microsoft's best practices. So the *fix cannot come from the Dispose layer.



Should the fix be implemented at a higher level such as the connection
object layer? After thinking about it, I don't think so for the same reason;
it forces the connection object into knowing more than it is supposed to
about the environment in which it is run. But this doesn't solve the
problem. The problem still remains that the benefits of the pool are being
negated. Why is this important? Consider a high volume website fielding
20000 hits per day. The benefits of pooling here make or break the website.
Negating these benefits is simply not acceptable and must be avoided. But
how can I avoid it if I don't know the negative effects?



What I am suggesting is that Microsoft append a qualifying comment to the
dispose pattern literature indicating that the using construct which
implements the IDispose pattern not be used in combination with object
pooling for web applications because the benefits of pooling may be
negatively affected. With that recommendation in the literature, I can
safely avoid the using construct at a high level and choose to manually
close my objects guaranteeing that the connection pool benefits remain in
effect since calling close() only flags the object for reuse anyway.





connection pooling?



No, I am not 100%sure. But based on the literature, I make an educated guess
that it ignores pooling because the dispose implementation must make no
assumptions about the environment.

The Dispose() implementation is provided by the class - so it knows the
environment intimately.

For SqlConnection, IDisposable.Dispose() simply calls
SqlConnection.Close() if the connection is not already closed. So it
handles pooling just fine (at least as well as Close() does).

 

[Sami Vaaraniemi]

so what exactly is the point of this in a web page (windows forms doesn't
care about pooling for the most part because it is not inherently
expensive).
using(MySQLConnection cn = new MySQLConnection (Global._connString3))

{

}

I am not in agreement with this implementation at all. Because it is
inherently costly at the expense of being safe. Is it an either safety or
performance cake? That totally negates the benefit of connection pooling. It
should come with a disclaimer as well because I always assumed it worked
with some sort of intelligence.

SqlConnection.Dispose calls SqlConnection.Close which puts the physical
connection back to the connection pool. The physical connection is *not*
closed or destroyed at this point. AFAIK the same applies to MySqlConnection
class with the ByteFX provider.

Likewise it is relatively cheap to call 'new SqlConnection' because only the
first call (per connection string) actually creates a physical connection.
Allocating SqlConnections with the 'using' pattern is the best way as it
plays well together with the connection pooling.

Sami

 

[Jon Skeet [C# MVP]]

Probably I was misunderstood. I'll restate for clarity.

I think you misunderstood our response

Implementing the using construct disposes of the object in question. The
connection pool is specifically setup to prevent object destruction because
it is inherently expensive to create this object. It is much more efficient
to reuse the object instead of destroying it.

Yes. However, that object isn't necessarily visible at all.

This behavior poses no problem in a windows environment because connections
are cheap, however, the reverse is true in a web environment.

Well, some connections are cheap. Database connections aren't, in
general.

Should the dispose pattern be smart enough to detect pooling? After thinking
about it, Jon is right. Because of how the finalizer works, it is faulty to
place dependency in the overridden dispose function. So it cannot check for
a connection pool flag before destroying the object, at least based on
microsoft's best practices. So the *fix cannot come from the Dispose layer.

I don't believe there's any fix required...

Should the fix be implemented at a higher level such as the connection
object layer? After thinking about it, I don't think so for the same reason;
it forces the connection object into knowing more than it is supposed to
about the environment in which it is run. But this doesn't solve the
problem. The problem still remains that the benefits of the pool are being
negated. Why is this important? Consider a high volume website fielding
20000 hits per day. The benefits of pooling here make or break the website.
Negating these benefits is simply not acceptable and must be avoided. But
how can I avoid it if I don't know the negative effects?

The connection layer hides it from you entirely - and it's entirely the
*right* place to put the knowledge, as only the connection layer knows
about what is really cheap and what is really expensive.

What I am suggesting is that Microsoft append a qualifying comment to the
dispose pattern literature indicating that the using construct which
implements the IDispose pattern not be used in combination with object
pooling for web applications because the benefits of pooling may be
negatively affected. With that recommendation in the literature, I can
safely avoid the using construct at a high level and choose to manually
close my objects guaranteeing that the connection pool benefits remain in
effect since calling close() only flags the object for reuse anyway.

No, you shouldn't avoid using the "using" construct - because chances
are that's exactly what *returns* the connection to the pool.

connection pooling?

No, I am not 100%sure. But based on the literature, I make an educated guess
that it ignores pooling because the dispose implementation must make no
assumptions about the environment.

Your crucial assumption is that the object you create is the one which
is expensive. That's unlikely to be true. What *is* likely to be true
is that creating the object (or more likely a call to Open) acquires an
expensive resource in some way. Now, calling Dispose (or Close) is
likely to return that expensive resource to the pool. It doesn't mean
the resource is destroyed so that it has to be recreated. Effectively,
the MySQLConnection object in your example is likely to be a wrapper to
some extent - when it's opened, it acquires an open connection from the
pool of *real* connections, and when it's closed, that open connection
is returned to the pool - which no doubt has its own policies for when
the real connections are closed (timeouts etc).

 

[Alvin Bruney [MVP]]

For SqlConnection, IDisposable.Dispose() simply calls

SqlConnection.Close() if the connection is not already closed. So it
handles pooling just fine (at least as well as Close() does).

well that's really what i was looking for. if that's true, the problem is
resolved then. and i assume mysqlconnection would follow that same pattern.
i was thrown off by this response which seemed to indicate to me at least
that this wasn't happening

Using should blindly call Dispose. It would be up to the object implementer
to write a Dispose method that works properly with the pooling system

phew. ok all is well now. you guys can go back to work.

thanks