Greetings, the current DBCP pooling implementation in org.apache.slide.store.impl.rdbms.JDBCStore has two major problems when used with an Oracle RDBMS:
1. the maxWait parameters is not set and cannot be configured 2. no validation query is set and cannot be configured
The default "maxWait" in Commons DBCP is -1, eg wait for ever when trying to acquire a new connection if the pool is exhausted. This setting will make Slide wait forever on line 311 (DriverManager#getConnection) in JDBCStore if the pool is full (ie maxActive has been reached).
An Oracle RDBMS will disconnect inactive JDBC clients, default timeout is somewhere around 8hrs. If this happens the stale pooled DBCP connections should be dropped by the object pool when the validation query fails, so that new fresh connections can be acquired after the server-side disconnect.
This is usually done with a validation query (for Oracle eg "SELECT 1 FROM DUAL") and the testOnBorrow/testOnReturn/testWhileIdle settings in DBCP/commons pool.
#2 is the most critical issue since it makes DBCP pooling in Slide useless in a production environment (if eg running Slide in Tomcat the Servlet container have to be restarted every morning if the app is inactive during the night).
I propose that we make all relevant Commons DBCP and Commons Pool parameters configurable through the Domain.xml, just like "maxPooledConnections" currently.
The configuration name "maxPooledConnections" is also slightly confusing since it controls the maxActive (ie max currently checked out Connection objects) setting in DBCP, not "maxIdle" which is the maximum allowed number of connections sitting idle in the pool. In my opinion "maxPooledConnections" suggests that one is controlling "maxIdle".
Therefore I also propose to rename "maxPooledConnections" to "maxActive" and for all new configuration settings to be named exactly as the Commons DBCP/ Commons Pool configuration settings. (The old setting can be kept as a backwards- compatible but deprecated alternative that works but will log a deprecation warning.)
Any thoughts on this? Unless someone has some issues with my approach I will start working on a patch.
Regards, Martin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
