commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Carmichael <>
Subject Prepared Statement pooling
Date Fri, 20 Feb 2004 01:52:38 GMT
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.  



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message