commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: [DBCP] Back pointers
Date Tue, 17 Jul 2007 23:39:35 GMT
BTW the reason we are getting ConnectionImpls instead of raw  
connections from the PooledDataSource is because  
PooledConnectionImpl.getConnection():159 wraps the raw connection  
with a ConnectionImpl.  The line of code is commented with "the spec  
requires that this return a new Connection instance".  If we didn't  
wrap, the back pointers would work, but we'd be violating the JDBC  
spec.  Once we wrap, we need to wrap all the statements and result  
sets so the back pointers are valid.

Another bug, is we're not tracking statements and result sets, so  
when the logical connection is closed the statements and result sets  
are not closed as required buy the spec.


On Jul 17, 2007, at 2:42 PM, Dain Sundstrom 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. 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?).
> Suggestion?
> -dain
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message