commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Carmichael <to...@concur.com>
Subject RE: [dbcp] [crosspost from dev] PoolableConnectionFactory validat ion and synchronized methods
Date Mon, 24 Nov 2003 19:45:59 GMT
Has your experience and feedback from others been that GenericObjectPool
'scales' better than GenericKeyedObjectPool?

Anyone else with perspective on this please chime in. 

Thanks.

ToddC


-----Original Message-----
From: Dirk Verbeeck [mailto:dirk.verbeeck@pandora.be] 
Sent: Saturday, November 22, 2003 6:03 AM
To: Jakarta Commons Developers List
Subject: Re: [dbcp] PoolableConnectionFactory validation and synchronized
methods


Todd,

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

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


Mime
View raw message