commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James House <ho...@trilobyte.net>
Subject Re: commons dbcp or pool problems
Date Sun, 24 Feb 2002 03:40:40 GMT

Actually, I had it working that way for a while too, but had complaints 
(in-house) about the extra thread...  But I'd be happy to throw it in.

I guess the question is:  Should this be in the standard DBCP stuff (with 
an on-off switch) or as separate classes only for use during debugging?

James

At 2/23/2002 08:11 PM -0600, you wrote:
>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