commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: [DBCP] Back pointers
Date Wed, 18 Jul 2007 04:39:06 GMT
On 7/17/07, Dain Sundstrom <dain@iq80.com> wrote:
> I'm working on a fix for the back pointers bugs DBCP-11 and DBCP-217
> where the Statement.getConnection() and ResultSet.getStatement()
> return the wrong objects.  The fix is pretty simple; we just need to
> make sure we wrap Statements and ResultSets returned from
> DelegatingConnection with the matching delegating type.

+1

 Anyway, I
> have the fix mostly complete with a bunch of test cases, but there is
> one problem...
>
> The PerUserPoolDataSource and SharedPoolDataSource classes return the
> ConnectionImpl class directly.   This class is a wrapper around the
> real connection so we need to wrap returned Statements which is easy
> enough.  The problem is these datasources use the
> CPDSConnectionFactory which does not call passivate on the delegating
> connection when the connection is returned to the pool so the
> Statements owned by the DelegatingConnection aren't closed.  To make
> matters worse, CPDSConnectionFactory can't call passivate anyway
> because it is in a different package and the method is protected :(
>
> At this point I'm not sure what to do.  I could fix the problem for
> all DataSources except for these two, and in the future we could
> rework these two to subclass PoolingDataSource.  Alternative, we
> could move CPDSConnectionFactory to same package as
> DelegatingConnection or make is a sublcass of some ConnectionFactory
> with access to the passivate method.
>
> I really do think these datasources should be brought in line with
> the main abstractions used by the other classes, but I don't think
> that is something for this release (maybe for 2.0?).
>

I think we should leave this alone for now and consider refactoring
for 2.0, but there is a semantic difference that we need to keep in
mind.  InstanceKeyDataSource (parent of PerUser and SharedPool)
sources connections from a ConnectionPoolDataSource.  These
datasources return connection *handles* (PooledConnection impls),
which are not the same as DelegatingConnections. The cpdsadapter
package is just there for older jdbc drivers that do not provide
ConnectionPoolDataSource implementations.  See the javadoc for
InstanceKeyDataSource and also the implementation of makeObject there.
 The key difference in the contract is that InstanceKeyDataSource
implements ConnectionEventListener, so when used with a driver that
correctly supports ConnectionPoolDataSource, the connection handles
handed out to users notify the pool (actually the factory in dbcp)
when they are closed by the user.  See connectionClosed in
CPDSConnectionFactory.

Phil

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


Mime
View raw message