commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject Re: commons dbcp or pool problems
Date Tue, 26 Feb 2002 00:02:29 GMT
Why not just create more connections when the pool is exhausted and then log
a warning message, so the bug can be tracked down later without breaking
production? Most databases can handle plenty of connections these days
anyways.

James
----- Original Message -----
From: "Glenn Nielsen" <glenn@voyager.apg.more.net>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Sunday, February 24, 2002 2:11 AM
Subject: Re: commons dbcp or pool problems


> I like this.  There is another option which could be added.
>
> clientTimeout
>
> It the pool exhausts its connections, it will review the list
> of connections in use, the connection which exceeds the clientTimeout
> by the most gets recycled.  If all the Statements are tracked,
> they can be closed (which closes any open result sets for those
Statements).
> And then the Connection can be closed.  A new connection would need
> to be created to replace the one recycled, then the old connection
> and Statement could get GC'd.
>
> This would help prevent those cases where a poorly written JSP page
> or Servlet doesn't close and release its JDBC resources from preventing
> others from getting a JDBC connection.
>
> Logging of misbehaving JSP pages and servlets is important.
>
> I am all for adding the below patch and the option above.
>
> It sure would have saved me some time the last few days. :-)
>
> Regards,
>
> Glenn
>
> James House wrote:
> >
> > At 2/23/2002 01:25 PM -0600, Rodney Waldhoff wrote:
> > > > A few months back I made my own hacks to
> > > > DBCP in order to have it find places in
> > > > our code that didn't free up DB resources
> > > > properly.
> > > >
> > > > I was able to generate class names and
> > > > line-numbers (stack trace) for every place
> > > > in the code that a statement or result set
> > > > was created but never closed, and also able
> > > > to track where connections were borrowed
> > > > and never returned.
> > >
> > > > If anyone's interested, I could try
> > > > digging it up, and posting it.
> > >
> > >Sounds great, especially if we can do it relatively unobtrusively (or
> > >optionally).  By all means, put together a patch.
> >
> > I'll be happy to put together a patch.
> >
> > First let me know what the preference is of how it fits in:
> >
> > Background:
> >
> > The changes affect the following classes:
> >
> > PoolableConnection
> > PoolableConnectionFactory
> > PoolingDataSource
> > DelegatingStatement
> > DelegatingResultSet
> > DelegatingPreparedStatement
> > DelegatingCallableStatement
> >
> > The changes basically entail adding Lists to the objects to keep track
of
> > the sub-objects that they've made, and also adding a member variable
that
> > hold a reference to an Exception that is created (but not thrown) at the
> > time the Connection was borrowed or  at the time a Statement / ResultSet
> > was made... so that it can be used to generate a stack trace that shows
the
> > code that borrowed/created the resource, when we detect that it wasn't
> > closed/returned properly.  This detection is done by removing the
objects
> > from the before mentioned lists as close() is called on them, and then
> > checking if there are still objects in the lists when the connection is
> > returned to the pool, or by calling a new method "detectLeaks()" on
> > PoolingDataSource to find un-returned connections.
> >
> > So you can see the changes aren't extremely intrusive (as far as
changing
> > existing code) but do ADD roughly 10 - 35  lines of code to each of the
> > classes listed above.
> >
> > Option One:
> >
> > Create a patch that alters these classes, and allows you to turn on/off
the
> > debugging features at the time you create your instance of
> > PoolableConnectionFactory.
> >
> > Option Two:
> >
> > Create new versions of these classes that have the feature always on,
and
> > you simply use a class named something like
> > "DebugPoolableConnectionFactory" instead of "PoolableConnectionFactory"
as
> > you create your datasource.
> >
> > Also, I submitted a couple suggested patches back on January 17th (2
> > separate e-mails to this mail list with the subject starting with
[DBCP]),
> > but never heard any response - albeit I didn't submit formal patches.
> >
> > I'd be happy to create these patches at the same time if you agree with
them.
> >
> > James
> >
> > --
> > To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>
> --
> ----------------------------------------------------------------------
> Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
> MOREnet System Programming               |  * if iz ina coment.      |
> Missouri Research and Education Network  |  */                       |
> ----------------------------------------------------------------------
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message