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 Sat, 23 Feb 2002 23:18:45 GMT


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>


Mime
View raw message