commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: jcl blog post
Date Wed, 16 Feb 2005 21:09:09 GMT
On Wed, 2005-02-16 at 06:57, Kevin A. Burton wrote:
> Craig McClanahan wrote:
> >On Tue, 15 Feb 2005 22:50:51 -0600, Vic <> wrote:
> >  
> >
> >>oops :-[
> >>Wrong link, this is it:
> >>
> >>
> >>It talks about Commons logging, since i'ts open season.
> >>.V
> >>    
> >>
> >
> >There's lots of ways to shoot yourself in the foot the same way ...
> >you don't need JCL to do that ... pretty much any implementation of
> >the factory design pattern should be looked at with suspicion.
> >
> >By the way ... if you use [chain] you should *really* pay attention to
> >the Javadocs for CatalogFactory.clear() ;-)
> >  
> >
> You know I have a similar little story about Commons DBCP.
> Its evil.. pure evil! ;)
> I actually rewrote it from scratch because I needed a good connection 
> pool implementation and DBCP just wasn't cutting it but it was 85% there.
> So one weekend I gutted the core and wrote my own pool implementation 
> and increased performance significantly.
> The key part for me was that for SOME reason in my highly multithreaded 
> app it would bleed connections. After about 48 hours our app wouldn't 
> have any more connections and all my threads would sit there sleeping 
> waiting for connections that would never come.
> Anyway... I called my newborn connection pool BDCP (basic database 
> connection pool).
> Its about 1/5 the size of DBCP and a LOT easier to maintain.
> Anyway... I was considering OSSing it here in the future but didn't know 
> how to approach it with commons-dbcp folks...

a lot of the stuff which was created in the early days of the commons is
pretty mature: either it's been taken as far as it can, or as far as the
limitations of original design (and so backwards compatibility) or by
conception (the limitations set by the original creators). there is a
place for well maintained, relatively well tested and well used
libraries. there is also a place for new libraries offering potential
benefits but which aren't as well tested in production. 

however, it's also important to be positive about the benefits offered
by the new (as opposed to simply being negative about the old). it's not
unusual for better designs to emerge by discussing different approaches
to the same problem.

- robert

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

View raw message