commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christoph Kutzinski" <ku...@gmx.de>
Subject Re: [POOL] Offer of help for a 1.4 release
Date Tue, 04 Dec 2007 14:29:01 GMT
Hi,

> On Dec 2, 2007 2:24 PM,  <kutzi@gmx.de> wrote:
> > Phil Steitz wrote:
> >
> > >> - fully synchronized borrowObject() and returnObject() methods. I've
> > >> seen this to be a serious bottleneck when the database is under high
> > >> load and another connection needs to be created.
> > >
> > > Agreed.  Ideas on how to improve this without creating threadsafety
> > > issues would be appreciated.
> >
> > I have started to implement a solution which has the basic idea to
> > return a (Java 5) Future<Connection> instead of a Connection on
> > borrowObject().
> > If we still have a pooled Connection I return an 'ImmediateFuture'. If a
> > new connection is needed, I return a FutureTask which creates the new
> > connection. The Task is executed by a SingleThreadExecutor with an
> > unbounded queue. Thus the blocking on connection creation is moved to
> > the caller thread and the pool is open for other threads.
> > However I'm still not 100% convinced with this solution. E.g. I would
> > like to immediate return a pooled connection to the waiting caller
> > thread, if a connection is returned to the pool meanwhile.
> >
> > Also, I understand that Java 5 is probably no option for commons-pool,
> > as it must stay compatible with Java 1.4, right? But maybe you can take
> > some of my ideas and implement a similar solution?
> >
> 
> Yes, we need to stay 1.4-compatible in pool 1.4.  If I understand the
> ideas that you are presenting correctly, this is sort of how pool used
> to work before the additional synchronization was added in pool 1.3.
> If you look back at the 1.2 codebase, the factory methods were mostly
> executed by client threads not holding locks on the pool.  I think we
> should be able to safely revert to that setup by taking a more
> surgical approach to deal with the threadsafety issues that the
> synchronization was added to address.  More to follow on this.

I took a look at 1.2's GenericObjectPool now. And no: that's not what I meant. In my solution
an (one) extra thread is handling the connection creation. All client threads which want a
connection past the current idle connection limit wait for this thread to finish. This way
it is still guaranteed that just one connection at a time is created (which is a good thing
IMO). I can send you my - still not complete - implementation, which will probably tell you
more than I can do with words.


greetings
Christoph

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


Mime
View raw message