RE: [DBCP] : DelegatingConnection/PoolableConnection Bug ?

[Paulo Gaspar <pa...@krankikom.de>]

> Returning a new Connection object in response to each 
> getConnection call is
> possible, but would take some refactoring.  

Rodney,


I still think it should have been done from the start like that.
This was the most important reason (although not the single one)
why I ended up implementing my own stuff.(*)

BTW, I still don't understand why pooling PreparedStatements is
such a popular feature. In which situations do you use it?


Regards,
Paulo Gaspar


(*) In case someone asks why I never posted it: 
It works, it has lots of features, but it is a mess and cleaning
its code is a very low priority for me at the moment. 

Besides, John McNally seems to be improving this stuff in the 
direction I like.


> -----Original Message-----
> From: Waldhoff, Rodney [mailto:rwaldhof@us.britannica.com]
> Sent: Wednesday, April 03, 2002 2:13 PM
> To: ''Jakarta Commons Developers List' '
> Subject: RE: [DBCP] : DelegatingConnection/PoolableConnection Bug ?
> 
> 
> I wrote:
> 
> > I'm also a little confused as to 
> > its purpose, but it shouldn't be too
> > difficult to do the wrapping at the 
> > Pool level instead of the PoolableObjectFactory 
> > (ConnectionFactory) level.  This may 
> > actually simplify a number of things, in 
> > addition to making the behavior you describe:
> > [...]
> > easy to do as well.
> 
> But on second thought, there's a reason DBCP isn't creating a new wrapper
> each time: DBCP supports PreparedStatement pooling, and these 
> statements are
> pooled per Connection.  When pooling statements, we need to keep 
> around the
> pool of Statements, and we need be able to associate the pool with its
> Connection.
> 
> Returning a new Connection object in response to each 
> getConnection call is
> possible, but would take some refactoring.  I have fixed the isClosed bug
> Anjan reported though, as discussed in a separate email.
> 
> - rod
> 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>