commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk Verbeeck <>
Subject Re: [dbcp] PoolableConnectionFactory validation and synchronized methods
Date Sat, 22 Nov 2003 14:03:04 GMT

Your issue is a different from the performance increase Brad proposes.
He is talking about a BasicDataSource pool like system with 
PoolableConnectionFactory and a GenericObjectPool.
This pool is already optimized, the GenericKeyedObjectPool isn't.

I don't agree with your statement that the physical connection to the database 
needs to occur lazily and inside activateObject.
The physical connection should be created in makeObject but the pool should be 
  optimized not to synchronize the calls to makeObject.

The maps in KeyedCPDSConnectionFactory have something to do with the jdbc2 
ConnectionEvents (see cpdsadapter.ConnectionImpl.close()).
Some synchronization is needed to protect these maps.

-- Dirk

Todd Carmichael wrote:

> The issue of high concurrency is very important to us as well.  What I would
> like to see is the narrowing of  the synchronization in borrowObject to
> include only grabbing a idle object or to making a new object and placing it
> the pool.  Activation of the object should NOT be sychronized.  This is
> because activation should not have anything to do with the maintenance of
> the datastructures tracking the pool of objects themselves.  The one
> exception to this is testing an object that is being retrieved from the pool
> for use (testOnBorrow): the failure case of this test would need to be
> synchronized to handle removing the object from the pool.   
> In addition, the actual/physical connection to the database needs to occur
> lazily and inside activateObject.  Currently this occurs in makeObject.  I
> am speaking of the
> org.apache.commons.dbcp.datasources.KeyedCPDSConnectionFactory and
> org.apache.commons.pool.impl.GenericKeyedObjectPool.  The synchronization of
> the makeObject and that fact that it creates that actual physical database
> connection causes serious degradation any time a new connection needs to be
> created: no other call can execute borrowObject while a database connection
> is being created which takes a long time.  
> I have done a couple prototypes to work around this but have not spent
> enough time to get it fully functioning.  Part of my problem is that I am
> not familiar with nor understand the need for the WeakHashMap in
> KeyedCPDSConnectionFactory and that the object PooledConnectionAndInfo uses
> final members.  
> Anyway: +1 for removing the bottle neck on borrowObject when new objects
> need to be created.
> ToddC

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

View raw message