Here my current environment/configuration Oracle9i Enterprise Edition Release 9.2.0.1.0 Oracle JDBC Driver version - 9.0.2.0.0 java version 1.4.2_04 Jakarta Commons DBCP 1.2 Jakarta Commons Pool 1.2 Jakarta Commons Collections 3.0
Both client and database server are running on Windows 2000 Dieter > -----Urspr�ngliche Nachricht----- > Von: Dirk Verbeeck [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 11. August 2004 21:48 > An: Jakarta Commons Users List > Betreff: Re: [DBCP] Question to database reconnection > > > During the connection activation (when borrowing a connection) the > setAutoCommit and other connection init methods are called. > If one of these methods throws a SQLException then the connection is > also considered broken and removed from the pool. > > So if you are using one of the "default*" properties and the JDBC > driver correctly reports the SQLExceptions on the "set*" methods then > you don't need an extra validationQuery. > > Can you post the database+driver+config you are using? > Or even better, make a FAQ item of this in the DBCP wiki. > > -- Dirk > > Leber, Dieter wrote: > > I'm using DBCP 1.2 without using any validation of the connections > > (testOnBorrow = false, testOnReturn = false, > timeBetweenEvictionRunsMillis = -1). > > > > When shutting down the database during running the application, the > > request using a pooled connection realizes that the > database is down. > > Returning the connection to the pool seems to clean the > pool (i.e. the > > pool has no active nor idle connections any longer). > > > > Starting the database again and demanding a connection from the > > pool a new connection is returned which has never been in > the pool before. > > > > If this is right no reconnection handling is needed at all > because we always > > have valid connections every time the database was down and > started up again. > > > > Can anyone please throw any light on this behaviour!? Are there > > situations where the pool is not cleaned so that validation > is actually > > needed? > > > > Dieter Leber > > > > --------------------------------------------------------------------- > 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]
