tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ran <>
Subject Re: [tomcat 5.0] - DBCP pooling vs sharing a single open connection
Date Thu, 14 Dec 2006 00:01:32 GMT
Thanks Chris,

Would the expensive opening database connection a issue while using Named
Pipes ?
(is the cost mostly coming from TCP 3 way or the xact setup/resource
allocation on the db side for a new inbound connection ?)


On 12/13/06, Christopher Schultz <> wrote:
> Hash: SHA1
> Ran,
> Ran wrote:
> > In this
> > case, my bean should hold up on one connection until the bean instance
> gets
> > gc'ed (for a request/ session scope bean)
> You can never count on an object to get GC'd: you should always
> explicitly free resources whenever you are actually done with them. So,
> if you have a bean that needs a connection, get the connection, use it,
> and then return it to the pool (or close it, which is usually the same
> thing when using pooled connections).
> > For a bean that persists in application scope, I would close the
> connection
> > after query finishes.
> >
> > Do pooled connections remain open in the container while idle?
> Yes. That's the whole point of pooling. Most database connections have a
> high cost to establish, so you get better performance by holding idle
> connections open waiting for some request to use them. If you open a new
> connection for every request that needs one, you suffer from two problems:
> 1. Resource management. If you get a flood of traffic all at once,
>    you could open up many database connections and bring your database
>    to its knees. Any decent connection pool can limit the number of
>    connections it holds, so you know there is an upper limit on the
>    number of in-use database connections at any one time.
> 2. Performance. Opening a new connection each time you want to access
>    your database is costly. If you open up your connections on app
>    start, then you only pay the penalty that one time. Otherwise,
>    you will pay that penalty for every request that needs a database.
> - -chris
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla -
> iD8DBQFFgB+e9CaO5/Lv0PARAhdeAJ9CFR2143im9CWvrTnF8exIkq169gCeK9JB
> 4ILIuRcvXzHOYIkg9qd63ao=
> =3XJq
> ---------------------------------------------------------------------
> To start a new topic, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message