commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Carmichael <to...@concur.com>
Subject RE: Prepared Statement pooling
Date Fri, 20 Feb 2004 05:57:29 GMT
Yes.  I don't have exact numbers but quite significant.  

ToddC


-----Original Message-----
From: Bill Culp [mailto:c-william.culp@mci.com] 
Sent: Thursday, February 19, 2004 8:09 PM
To: Jakarta Commons Users List
Subject: Re: Prepared Statement pooling


Just curious,
Have you seen measurable performance improvement caching PreparedStatements?

- Bill
Todd Carmichael wrote:

>I need different behavior from the Prepared Statement pooling that is 
>implemented in the DriverAdapterCPDS (at least I think I do).  
>Basically I want the prepared statement pool to limit the number of 
>items pooled and if I am out of room, remove the least recently used 
>element to make room for the new one.  Perhaps that is not what a 
>'pool' is but that is our needs. We have issues with our prepared 
>statements in that many of them pass in constants that really should be 
>parameters, so our cache grows very large. We know this is a problem in 
>our code and will hopefully address this issue because it affects our 
>app server and db server performance.  But for now, our project does 
>not have time for this kind of refactor.  The evictor thread does clean 
>up those unused prepared statement, but I would like to set a hard 
>limit on the number of statements and if I reached the limit, evict the 
>oldest statement.  On a side note: the evictor thread on the prepared 
>statement will create a thread per connection which seems like high 
>overhead.  Right now the GenericKeyedObjectPool is used for pooling 
>prepared statements and the values for the pool are taken directly from 
>the values of the connection pool.  Is there a different pool 
>implementation or settings I could set to get this LRU type behavior?  I
may change the code to use the commons collections LRUMap, that seems like
it would have less overhead.
>
>Thoughts?
>
>
>ToddC
>
>
>  
>



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