Re: pooled connection myth

From: David McDivitt (x12code-del_at_del-yahoo.com)
Date: 03/17/05 

Date: Thu, 17 Mar 2005 14:26:37 -0600

>From: Lee Fesperman <firstsql@ix.netcom.com>
>Subject: Re: pooled connection myth
>Date: Thu, 17 Mar 2005 19:58:04 GMT
>
>David McDivitt wrote:
>>
>> There is much to be gained by reusing known open connection objects, rather
>> than issuing single use connection objects for each request. If connection
>> objects are not modified by using transaction blocks, there's no reason not
>> to share them between threads. The word "pooling" implies this, but pooling
>> itself doesn't do very much. For the most part, all that happens is caching
>> the database user name and password.
>
>As John said, the usefulness of concurrent sharing for connection objects varies by the
>driver. In addition, the Connection object does contain state information. Take a look
>at the various setXXX() methods in java.sql.Connection.
>
>Your assumptions about pooling are not very valid. Other types of resources, including
>threads, are pooled in Java but rarely concurrently. Concurrent use of pooled resources
>would tend to imply that all state be read-only, thus no pooling as such is not needed.
>All you need to do is to keep a common reference (GC will take care of disposing of the
>object when no longer needed). While this isn't absolutely true in all cases, it covers
>most of the interesting ones.
>
>Also, caching of connection properties is just one aspect and will normally include more
>than just user/password. Then there is the very important feature of avoiding the
>overhead of making (and ending) a connection to the db and resultant pressure on
>resources on the server. In addition, some connection pooling software support
>(automatic, hidden) pooling of prepared statements.
>
>Finally, please do not top-post. It's just basic netiquette.

If more functionality is present in the connection manager I want to see it.
I do not want to take it on faith. What you say here does not represent
enough value compared to increased complexity. Shared connections are good.
Pooled connections, are not good, since pooling itself does not accomplish
anything. The only way it can be of value is to intercept close and open
calls and reuse hot connections. This is not being done where I am.

Relevant Pages

  • RE: DCpromo issue. Health check on AD and group policy.
    ... new DC to create new inbound connection objects (You can't even via ... RAM / perf on most DC's, KCC was not autogening connection obj's. ... We have 2 DNS servers, Bart is the primary DNS server ...
    (microsoft.public.windows.server.active_directory)
  • RE: DCpromo issue. Health check on AD and group policy.
    ... inbound connection objects. ... KCC was not autogening connection obj's. ... We have 2 DNS servers, Bart is the primary DNS server ...
    (microsoft.public.windows.server.active_directory)
  • Re: VB-ADO-SQL Server : SQL Server performs logins after some queries
    ... It should not open new connection, ... > All recordsets in all procedure refer to this specific DB connection ... > Meanwhile I've found the origin of all my SQL Server errors that I faced: ... > not used to open one or more connection objects for different recordsets ...
    (microsoft.public.vb.database.ado)
  • Re: Replication Question
    ... The COs (connection Objects) are created based on the site and site links configuration. ... Generally you don't need to change anything unless the DCs don't have access to all existing DCs over wan because your network configuration may not permit that. ...
    (microsoft.public.windows.server.active_directory)
  • Re: pooled connection myth
    ... grouping is only done at the resource driver level. ... > reusability of connection objects created with this driver. ... > connection objects, necessarily, those connection objects go away. ... will often supply a class that will manage a connection pool for you. ...
    (comp.lang.java.programmer)