commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: [POOL] Offer of help for a 1.4 release
Date Sun, 02 Dec 2007 23:37:27 GMT
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.

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

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


Mime
View raw message