Thanks Mark, yes I have mixed together Tomcat JDBC 8 and DBCP 7, my bad. Although I don't understand why Tomcat JDBC don't use DBCP as default solution for connections pooling.
2015-06-02 16:59 GMT+03:00 Mark Thomas <[email protected]>: > On 01/06/2015 14:22, Tweak Ronaldo wrote: > > Hello guys, > > Assuming you don't want to limit your question to men only, you would be > better to use of of the following greetings: > Hello, > Hello all, > Hello folks, > > etc. > > > we have migrated to Tomcat DBCP 8.0.18 from 7.0.37 recently and > > faced the following issue: > > after database restart (Postgres), our application wasn't been able to > > restore connectivity to DB, all connections were closed and every time, > > after failed attempt to execute some SQL statement, returned back to > pool. > > Pool is configured with all tests (on borrow, on return, on connect, > while > > idle) disabled. Pool configuration is the same for 8.0.18 and 7.0.37. > > While using 7.0.37 DBCP is able to restore from DB restart, because > > PoolableConnection class performs explicit check if underlying SQL > > connection is closed: > > > > public synchronized void close() throws SQLException { > > if (_closed) { > > // already closed > > return; > > } > > > > boolean isUnderlyingConectionClosed; > > try { > > isUnderlyingConectionClosed = _conn.isClosed(); > > } catch (SQLException e) { > > try { > > _pool.invalidateObject(this); // XXX should be guarded to > > happen at most once > > } catch(IllegalStateException ise) { > > // pool is closed, so close the connection > > passivate(); > > getInnermostDelegate().close(); > > } catch (Exception ie) { > > // DO NOTHING the original exception will be rethrown > > } > > throw (SQLException) new SQLException("Cannot close > connection > > (isClosed check failed)").initCause(e); > > } > > ... > > > > My question is: why this check was removed and how can one get the same > > behaviour (of 7.0.37) using 8.0.18 (not using on borrow, on return, while > > idle validations, which are SQL queries)? I see that there is a property > in > > pool configuration which allows user to provide custom Validator, though > I > > don't want to go this way because DBCP configuration is performed by 3rd > > party library and we don't have direct access to it. > > The check to which you refer was not removed. It is still present in the > code base and - as far as I can tell from a quick look at svn - never > been removed. > > DBCP has no support for a custom validator. You appear to have confused > something else with Tomcat's port of Commons DBCP (the Tomcat JDBC pool > perhaps?). > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
