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


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

Re: Connection Pooling

Path csiph.com!x330-a1.tempe.blueboxinc.net!feeder1.hal-mli.net!news.glorb.com!news-out.readnews.com!news-xxxfer.readnews.com!news-out.news.tds.net!newsreading01.news.tds.net!86597e80!not-for-mail
From kuassi.mensah@gmail.com.remove-dii-this
Subject Re: Connection Pooling
Message-ID <5faa0a1f-03fa-4633-8008-06db242b8bb5@x1g2000prh.googlegroups.com> (permalink)
X-Comment-To comp.lang.java.programmer
Newsgroups comp.lang.java.databases
In-Reply-To <7fa97643-cfdd-4850-b40a-85e549ea749e@d1g2000
References <7fa97643-cfdd-4850-b40a-85e549ea749e@d1g2000
Content-Type text/plain; charset=IBM437
Content-Transfer-Encoding 8bit
X-Gateway time.synchro.net [Synchronet 3.15a-Win32 NewsLink 1.92]
Lines 42
Date Wed, 27 Apr 2011 15:22:02 GMT
NNTP-Posting-Host 96.60.20.240
X-Complaints-To news@tds.net
X-Trace newsreading01.news.tds.net 1303917722 96.60.20.240 (Wed, 27 Apr 2011 10:22:02 CDT)
NNTP-Posting-Date Wed, 27 Apr 2011 10:22:02 CDT
Organization TDS.net
Xref x330-a1.tempe.blueboxinc.net comp.lang.java.databases:150

Show key headers only | 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