commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk Verbeeck <dirk.verbe...@pandora.be>
Subject Re: Prepared Statement pooling
Date Sat, 21 Feb 2004 12:15:12 GMT
Prepared Statement pooling can improve performance, database servers 
do have their own server side cache but having a stmt reference from 
the client is better.

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


Mime
View raw message