commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hope, Matthew" <>
Subject RE: Using AbandonedObjectPool...
Date Wed, 09 Jul 2003 18:21:58 GMT
This practice is maladaptive.

the reason your pool has a fixed max size is because you wish to avoid
hammering your database or exceeding its concurrent connection limits.

if you run out of connections on a sufficient basis to cause serious waits
(or indeed deadlocks if its badly written) you should not be using something
like AbandonedObjectPool instead you should:

1) see if (while you do the below) you can increase the max poolsize

2) find out why you are holding onto a connection too long:
a) doh, you aren't returning your connections to the pool with close() 
fix (investigation): use something like p6spy to detect closures caused by
garbage collection
fix (code): *EVERY* instance of getConnection() should include a finally
clause at the end of it which closes the connection.
b) it's being grabbed at the beginning and then not used much for large
periods of time while another expensive operation occurs.
fix (non transactional): close the connection after the first use and get
one back when needed
fix (transactional): as above but use a product which ensures pooled
connections behave transactionally (I know weblogic does this, can Jboss?)
fix (transactional): make your transaction way around this,
make it faster, re-order it, split it up if you can but sort this out you
kidding yourself if you think there's any other solution
fix (stupidity): are you waiting on user actions before closing the
connection (or worse still opening a connection per user). don't do this -
it's not scalable.

3) sql just takes too damn long
fix (good): learn how to do better queries/db design/caching strategies to
sort it.
fix (bad): buy a bigger box

Who needs consultants really...

Matt Hope

> -----Original Message-----
> From: Rodrigo Reyes [] 
> Sent: 09 July 2003 18:48
> To: Jakarta Commons Users List
> Subject: Re: Using AbandonedObjectPool...
> Simon
>     That seems to be Ok. But what happens when I have a 
> reference to the
> DataSource in my app, but I have too many opened connections 
> due to a prior
> activity rise? Is there any way a connection gets closed when 
> it has been
> iddle for too much time? Wasn't that the reason for the existence of
> AbandonnedObjectPool?
>     I also know good code should always close its 
> connections. Still, is
> there some way to "iddle" active connections if they exceed a 
> certain amount
> of time being "active"? Thanx...
> Rodrigo
> ----- Original Message ----- 
> From: "Simon Kitching" <>
> To: <>
> Sent: Tuesday, July 08, 2003 6:08 PM
> Subject: Re: Using AbandonedObjectPool...
> > On Wed, 2003-07-09 at 09:53, David Graham wrote:
> > > --- Rodrigo Reyes <> wrote:
> > > > Thanx David...
> > > > But if this happens, how do I close connections when 
> the system no
> > > > longer
> > > > uses them?
> > >
> > > Your code should always close connections from the pool 
> when it's done
> > > with them.  Connections also get closed when they're 
> garbage collected
> so
> > > if your app stops using the DataSource or gets shut down 
> they will be
> > > closed.
> >
> > Note that when you call "close" on a pooled connection, 
> this *returns
> > the connection to the pool* rather than *closing the 
> connection to the
> > database*.
> >
> >
> > Regards,
> >
> > Simon
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail: 
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

View raw message