c3p0:JDBC DataSources/Resource Pools

I found out that when there is a memory leak during a long-lived tx using
c3p0, it is most likely created by not closing your resultsets and
statements appropriately.
This happens because there are several places where the pool keeps
references to resultsets, statements and connections (to be able to clean
the house at the end), and these references are freed only when you close
each resource in the proper way.

I found out that NewProxyResultSet instance created in
NewProxyPreparedStatement.getGeneratedKeys() method may not be closed.
Hence, it was not detached from eventlistenersupport properly.

We are seeing the same situation.
com.mchange.v2.c3p0.util.ConnectionEventSupport is holding references to
c3p0 proxy result sets.

...a memory leak is a valid criticism, and c3p0 strives not to have 'em,
regardless of any way you beat up the JDBC api without violating
standard-documented constraints. you c'n keep a transaction open your whole
life, if your DB is cool with that.

it's be good if you could reproduce that heap screenshot, though...
offhand, i can't think of why proxy result sets would be held referenced in
a long txn. except.

if you are keeping txns open very long, you should definitely be
close()ing your ResultSets promptly... c3p0 certainly won't clean 'em up
for you while the txn is still open! are you?

anyway, if you tell me who's pointing to what, that'd be helpful.

smiles,
Steve