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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
