Re: Question about IDispose

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Jon Skeet [C# MVP] (skeet_at_pobox.com)
Date: 02/25/04 

Date: Wed, 25 Feb 2004 08:43:32 -0000

 <"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:
> 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.
 
> >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.

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). 

-- 
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Relevant Pages

  • Re: Random database connectivity failure
    ... We can’t find any problems with the pooling, that it uses to many resources. ... pointing to its not a pool problem. ... The server is only used for this web-application, ... white paper on handling the connection pool on my website. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Question about IDispose
    ... > SqlConnection.Close() if the connection is not already closed. ... > handles pooling just fine does). ... >to write a Dispose method that works properly with the pooling system ... >> are cheap, however, the reverse is true in a web environment. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Question about IDispose
    ... > connection pool is specifically setup to prevent object destruction because ... > place dependency in the overridden dispose function. ... The benefits of pooling here make or break the website. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: ADO - Bad when it is time to Optimize
    ... tells the settings to be done after ADO pooling is turned off, ... I think the reason for that is ADO Pool goes ... on creating new connections when it finds no free connection in the ...
    (microsoft.public.data.ado)
  • Re: Problem with database connectivity performance
    ... can you confirm that only one pool is getting created ... ... generate error messages, ADO.NET exceptions. ... If we use connection pooling we ... If we turn off connection pooling we are getting the following exception ...
    (microsoft.public.dotnet.framework.performance)