Hi, > On Dec 2, 2007 2:24 PM, <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
