THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="01f15e6665ab3822-5d1331dc-4b334777-81e8b4a8-7c8dc6a1af5113c04fffbb0b"><ac:plain-text-body><![CDATA[ | http://jakarta.apache.org/commons/dbcp/images/dbcp-logo-white.png | [http://jakarta.apache.org/commons/dbcp/ Commons-DBCP] provides database connection pooling services.[BR]A lot of information is available on the [http://jakarta.apache.org/commons/dbcp/ DBCP website]. If you don't find the information you need you can always contact us using one of the [http://jakarta.apache.org/site/mail2.html#Commons mailing lists]. | ]]></ac:plain-text-body></ac:structured-macro> |
...
A: They were replaced: http://cvs.apache.org/viewcvs.cgi/jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/PoolableConnectionFactory.java?r1=1.22&r2=1.23&diff_format=h
...
Q: Without using validation of connections (testOnBorrow = false, testOnReturn = false, timeBetweenEvictionRunsMillis = -1) and after shutdown and restarting the database again, it looks like the pool is cleaning its old connections by itself. So it turns out that we always have valid connections. How can you explain this and when is explicit validation necessary?
A: 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.