Re: pooled connection myth

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

Date: Thu, 17 Mar 2005 16:59:27 -0600

>From: Lee Fesperman <firstsql@ix.netcom.com>
>Subject: Re: pooled connection myth
>Date: Thu, 17 Mar 2005 22:31:32 GMT
>
>Thanks for responding (and for inline posting). I don't know the connection manager that
>you are using. Note: ConnectionManager is a specific facility in JCA; this is probably
>not the JCA one. The one you're using may be a poor facility, however you also made
>assertions about connection pooling in general which aren't valid.
>
>I think I did list the major benefits of connection pooling. The one I missed was
>reduced resource requirements and better control of such by the containing software (for
>one thing, it gives the container the ability to say: you can't have another connection
>at this time.) If those are not of interest to you, fine, though tighter control of
>resources is quite important to many containers. For instance, JCA gives the container
>control over the use of threads by connectors.
>
>As to shared connections, I see that to be of very limited use. I made comments on that
>in the other sub-thread and would be interested in your counter. If you also look at the
>thread on comp.lang.databases (I'll get the title if you wish), you will see arguments
>why a server would not want to increase that capability.

Yes, please give me something for a text search in that newsgroup. I do not
download it so should start.

If a database driver will handle multiple threads on one connection, even if
serialized, that is by far the best scenario. The connection manager I made
makes my application incredibly fast. All it does is return the same three
connections round robin. I had ten people hit it as fast as they could, over
and over, at the same time for a test. No one has said what is actually
"pooled" in connection pooling. It is a myth. When closed the connections go
away. If their number increases and decreases dynamically, that means they
are being opened and closed. Realize that each open is a separate login to
the database server requiring user name and password. There is no possible
way you can show that to be more efficient than sharing a few connections
and never closing them. Limited functionality is given to a caller, yes, but
the only limitation is trans blocks. For those a standalone can be obtained.

Relevant Pages

  • Re: Tryin to develop a jca connector
    ... What you're missing here is the JCA (Client) Connection class can be ... JCA has no requirements for this class. ... Connection Factory. ...
    (comp.lang.java.programmer)
  • Re: DriverManager vs. DataSource?
    ... > class to establish the connection. ... it is possible to use the DriverManager interface. ... JDBC driver jars go in a 'common' directory in the container. ... > the DataSource interface will typically be registered with a JNDI ...
    (comp.lang.java.databases)
  • Re: Cingular Connection Manger tweeks
    ... connection speeds using Cingular's Connection Manager and Windows DUN ... not just the Cingular Connection Manager. ...
    (alt.cellular.cingular)
  • Re: Strange Repadmin objects
    ... Open the ADSI Edit MMC snap-in. ... In the Connection Settings dialog box, in the Name field, enter a name for the ADSI connection. ... Right-click the object or container, click Delete, and then click Yes. ... This posting is provided "AS IS" with no warranties, ...
    (microsoft.public.windows.server.active_directory)
  • Re: 802.11 Association not noticed by device
    ... I've used several support ... cases for CE and guess what - I'm not an OEM. ... I've learned that the cause of my problem is The Connection ... or get rid of Connection Manager entirely and replace ...
    (microsoft.public.windowsce.embedded)