takiguchi <taktos(at)gmail(dot)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