takiguchi <tak...@gmail.com> wrote: > This is a problem of connection pooling, not of transaction. > > 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. > } > } > } > > Because rollback() throws no exception when physical connection has > been closed, I cannot know whether rollback was successfully > completed. > In general, if rollback() throws NO exception, it must be a success. > (Success means rollback process is executed, and ended successfully. > This represents that connection could access to server.) > > I think if physical connection has closed, Connection's method > should fail and throws Exception. That's sort of an odd construct, but I see your point. Checking the javadocs, I see that they very explicitly support your position. http://java.sun.com/javase/6/docs/api/java/sql/Connection.html#rollback%28%29 | SQLException - if a database access error occurs, this method is | called while participating in a distributed transaction, this method | is called on a closed connection or this Connection object is in | auto-commit mode This is indeed a bug. No doubt about it. Since it is a JDBC driver bug, it might be best to post to that list, with a reference back to this thread. Do you want to put together a JDBC driver patch, or should I? -Kevin
-- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs