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.
--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... <"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote: 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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
