Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.databases > #150

Re: Connection Pooling

From kuassi.mensah@gmail.com.remove-dii-this
Subject Re: Connection Pooling
Message-ID <5faa0a1f-03fa-4633-8008-06db242b8bb5@x1g2000prh.googlegroups.com> (permalink)
Newsgroups comp.lang.java.databases
References <7fa97643-cfdd-4850-b40a-85e549ea749e@d1g2000
Date 2011-04-27 15:22 +0000
Organization TDS.net

Show all headers | View raw


  To: comp.lang.java.programmer
> Hi Kuassi!
>
> It seems to me that any DBMS-resident 'pooling' or any change that
> makes a client's wait to get a new real connection shorter, would
> be a good thing, and unless it imposes some new limit on the number
> of connections, it seems it would be beneficial independently of
> whether there is any pooling at the client side. For any client
> architecture and distribution, it would be always important to
> design a client-side pool to collect only the number of connections
> actually needed by the client, so I would say that the problem of
> over pre-allocation can be avoided, and indeed many pool allow a
> discharge of unneeded connections after a time limit, so a good
> client-side pool can maintain only what it needs.
>    Is a DBMS-resident connection 'pooling' a good answer for the
> application profile you suggest, with 4000 middle-tier clients,
> each averaging 10,000 in-use connections, and a random flux of
> making up to 10,000 more as needed and closing them when not?
> Joe

There is a socket creation (to the connection broker) during the very
first connection request from a client/middle-tier. When the
connection is returned to the pool, the socket is retained so that
subsequent connection requests do not pay that one-time socket
creation price.

DRCP does not impose a limit on the number of connections that a
client may request from the pool.

Yes, DRCP addresses the problem of over-allocation of database
connections (and the memory consumption) as a result of each client-
side middle-tier sizing its pool to avoid wait time. In a non-
centralized pooling (hundreds/thousands of middle-tier pools), there
is no way to meet the average in-use connections without over-sizing
or incurring expensive database connections creation/destruction.

Kuassi

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

Back to comp.lang.java.databases | Previous | Next | Find similar


Thread

Re: Connection Pooling kuassi.mensah@gmail.com.remove-dii-this - 2011-04-27 15:22 +0000

csiph-web