commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Waldhoff, Rodney" <>
Subject RE: [dbcp]: Oracle "too many open cursors error"
Date Tue, 07 May 2002 18:25:25 GMT
> I patched dbcp's PoolableConnection class to 
> keep track of any statements created on the 
> connection, and have the passivate() method 
> close them all. This worked great for me, 
> until I saw that caused a test case to fail.
> Apparently, BasicDataSourceFactory is a special 
> case, because it doesn't use the statement pool 
> like the rest of the code.  Is this an oversight?

Not an oversight.  BasicDataSource simply doesn't use PreparedStatement
pooling, so it's safe to close all the Statements when the Connection is
returned to the pool.  With PreparedStatement pooling (as Berin notes) I
think we'll want to close the ResultSet objects, but not the physical
statements when the Connection is returned to the pool.  I think JD Evora's
note is heading down the right path.  Feel free to forward a description of
your changes as well, that sounds like a good start.

> Also, would the statement pool engage in any 
> kind of eviction, to limit the total number of 
> open statements at any given time?  

Yes, depending upon the configuration and/or pool-implementation being used.

The current KeyedObjectPool implementations in commons-pool (and therefore
the "public" prepared statement pools available to DBCP) allow one to cap
the number of pooled-objects per key, and GenericObjectPool will actively
evict pooled objects that have been idle for too long.  

None of the public KeyedObjectPool implementations provide a cap on the
total number of objects, or on the the number of unique keys that can be
used, but its certainly possible to do so.  (This may in fact lead to
problems if you're pooling prepared statements *and* have a very large
number of unique prepared statements *and* keep Connections around in the
pool for some time.  It's actually something I've run into before, but only
when client code was programmatically generating prepared statements (and
not using bind variables at all, which sort-of defeats the purpose of using

- Rod

> -- Bill

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