(please forgive my last message that got cut off) I've been using the dbcp BasicDataSourceFactory with Tomcat, as a replacement for Tyrex brokenness. I ran into some trouble with it under heavy load: after running it for a while I end up with an Oracle "too many open cursors error".
The problem is a combination of dbcp code and application code. The application code was written with the assumption that calling conn.close() resets and frees all resources associated with a connection, closing any associated statements. This worked fine until bringing in DBCP, because the underlying connection stays open--with all its open statements. The result is Oracle running out of cursors. 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? Also, would the statement pool engage in any kind of eviction, to limit the total number of open statements at any given time? Caching statements seems like a good idea for performance, but can also be a resource leak. -- Bill -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
