takiguchi <taktos(at)gmail(dot)com> wrote:
> public void testConnection() {
> Connection con = dataSource.getConnection(); // get a connection
> from pool (If DB server restarted, invalid connection will be
> returned)
> boolean valid = true;
> try {
> // execute some DMLs...
> con.commit();
> } catch (SQLException e) {
> try {
> con.rollback();
> } catch (SQLException e) {
> valid = false; // UNREACHABLE
> }
> } finally {
> if (valid) {
> con.close(); // Connection#close() doesn't close
> connection in reality in connection pooling mechanism. It simply
> returns the connection to pool.
> }
> }
> }
I'm looking at the JDBC driver, and so far I can't see why a rollback
attempt wouldn't generate a SQLException when the commit attempt did
so for a broken connection.
Is it possible that you have autoCommit set to true? The driver is
currently skipping the commit or rollback attempts when that is true,
which is improper; but I'm not sure you're going to be very happy with
the above code if we make it behave like the Sun javadocs require,
either. With autoCommit set to true, *any* commit or rollback attempt
should throw an exception, so in that case the above code would never
return a connection to the pool, nor would it close the connection
properly.
This makes me concerned that fixing the bug in the JDBC driver could
expose serious bugs in application code, and break things which are
currently working, for some values of "working". :-(
-Kevin