Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.databases > #150
| 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
Re: Connection Pooling kuassi.mensah@gmail.com.remove-dii-this - 2011-04-27 15:22 +0000
csiph-web