commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject Database Connection Pool
Date Sun, 23 Dec 2001 05:40:31 GMT
With so many reference to database connection pools I have to ask:
 - Are you not happy with DBCP?

Things I miss on DBCP:
 - The wrapping is not complete;
 - Not enough pool behavior control;
 - No easy way of closing all Statements and ResultSets related to a
   Connection.

So, I was NOT happy with DBCP and what I wanted to change was too 
much to make it just by posting patches. So I built one, learning 
from DBCP and using lot of its code in the process.

And I could use some more pairs of hands and eyes to improve it and 
make sure there are no further bugs (it already has some full days 
of testing). Also, I am still not happy with some details and could
use other's opinions.

So I would like to contribute it to the commons. If you want to 
take a look I will post it as I am doing with the logging stuff.

I am asking because it will still take some hours to make sure it
works alone (without the rest of the framework). If you all love
DBCP and do not care to spend time looking at other stuff I can
save that time.

(Anyway, I am starting to divide some of my stuff into subprojects
and I will end up isolating this one too one of these days.)


Differences from DBCP:
  - Complete wrapping, providing the possibility to close all the
    Statements and ResultSets depending of a Connection;

  - Possibility of closing all the Connections (hence Statements
    and ResultSets too) of a "client" DataSource - you can have a
    "server" DataSource that wraps the pool and a "client" 
    DataSource that you can use for a thread (like in a Servlet)
    and close at the end of its use (like at the end of processing
    a Servlet request). This helps to ensure proper cleaning up;

  - More control over the Pool behavior (how it grows and how it 
    shrinks);

  - Different underlying Pool;

  - NO Keyed Pools (my poor brain gets confused with those) and NO
    statement caching (IMHO too much complexity for such low gain);

  - Possibility of using a thread pool for the cleanup stuff.


BTW: it works.

Please tell me if you are curious to see it.


Thanks and have fun,
Paulo Gaspar


> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@octo.com]
> Sent: Saturday, December 22, 2001 8:09 PM
> To: commons-dev@jakarta.apache.org
> Cc: avalon-dev@jakarta.apache.org
> Subject: Synergies between Avalon and Commons projects ?
> 
> 
> I'd like to have your opinion on the possible synergies between Avalon
> and the Commons projects on reuse and sharing.
> 
> Here are some of my thoughts :-)
> 
> * Avalon is a service framework (ok, component and service framework)
> and is suited for lots of projects but some projects may not need/want
> to use the small Avalon wrapper which is layered on top of the java
> classes and may want to use directly the implementation (like using a
> jdbc pool but not as an Avalon component which needs to be managed by a
> component manager)
> 
> * On the other hand, Commons is geared towards providing context neutral
> libraries which could be used in any context.
> 
> * Thus, one solution could be to put in Commons the bare implementation
> (like the jdbc pool implementation) and put in Avalon a component
> wrapper on top of it (and reference the commons jars).
> 
> ...

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


Mime
View raw message