commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Culp <>
Subject Re: Prepared Statement pooling
Date Fri, 20 Feb 2004 04:08:37 GMT
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.  

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

View raw message