Here, we are using slide 2.1 with store on 
org.apache.slide.store.impl.rdbms.OracleRDBMSAdapter
We have a max connection pool size of 5 for tests purpose (our db admin became 
crazy when we put a value of 50 and, due to some bug, tomcat was consuming 
those 50 connection, three times, making 150 session on oracle server). I 
never noticed any problem, though i let the test server run for about 3 days 
without restart. I didn't have to start it back in the morning and nobody was 
supposed to access it during the night. I'll try this afternoon to put it 
under stress so as to 'consume' the whole connection pool and see if anything 
happen after a night of sleeping. Am quite surprised i saw no problem for 5 
months of developpement on an oracle connection if oracle store is so 
unsuable in production environnement.

regards,

-- 
David Delbecq
Royal Meteorological Institute of Belgium

Le Mardi 19 Avril 2005 13:07, Martin Kalén a écrit :
> 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]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to