The limit you should use is maxTotal on GenericKeyedObjectPool.
But if you start using this new parameter for larger stmt pools you might want to implement the following enhancement:
http://jakarta.apache.org/commons/pool/xref/org/apache/commons/pool/impl/GenericKeyedObjectPool.html#782
Only remove one stmt and not simply clear the whole stmt pool when the limit is reached.
-- Dirk
Todd Carmichael wrote:
If I am reissuing the same sql query many times, there will be a decent
payback to caching the preparedstatement object returned from the call to
preparestatement from the client (java and jdbc in our case). If I do not
reuse the same preparedstatement object (i.e. not using preparedstatement
caching), I must reissue the call to preparestatement which I am sure at
minimum is a network round trip and other overhead. If you look at
connection pooling provide by the major application servers like Sun ONE and
Weblogic, they all provide prepared statement caching.
Our problem is that we are calling preparedstatement on queries that really
shouldn't be prepared because they are unique and will not occur again.
That is our problem that we need to fix at some point. However, for right
now I searching for a workaround by limiting the amount of preparedstatement
objects we cache.
ToddC
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
