Question

JDBC调用存储过程,存储过程中事务回滚,报错

JDBC 调用存储过程,然后存储过程里面 本身写有事务 ，然后回滚了，然后到JDBC这边的时候，事务无论提交也好还是回滚也好，都会报“服务器无法继续执行该事务”，根据我的理解，存储过程里面的事务回滚了，到JDBC层面，不管rollback还是Commit都还在操作同一个事务，但是我又奇怪，无论事务回滚或者成功 不都意味着 这是事务结束么，为什么在JDBC 会报这样的错呢。

Answer 1

ConnCloseThread中关闭连接的时候，不是立刻返回的。Connection.close()会触发Connection.commit()，而因为调用的存储过程中，存储过程起了自己的事务，connection.commit()必须等到存储过程结束才能完成(这个是microsoft论坛上看到的)。如果所有connection.close()都等到tx commit或rollback完成才执行的话，这个问题就不会出现了
从测试结果来看，凡是close connection耗时比execute statement短的，连接（物理连接）都会报出该问题。分析原因：通过weblogic datasource获取的connection并不是物理connection，而是由weblogic wrapped的connection。这些conection在被close后，并不会关闭物理连接，而只是将物理连接还池。我们对connection的所有操作，最终都会被delegated到底层物理连接上，即commit()，rollback()最终都是在物理连接上执行。如果上面的connection.close()，底层物理连接没有等到存储过程事务结束就返回的话，那么物理连接上应该还带有此次操作的事务，而weblogic这边不会关系物理连接的情况，直接将连接放入connection pool供其它客户端使用。这时候如果设定了test on reserve的话，下次客户端从data source获取连接时，weblogic会检查这个物理连接，作一个select操作的，这个有问题的连接就会暴露出来，也就是上面的异常。这个问题如果使用driver manager来获取连接的话（如果每次都关闭的话），则不会出现，因为使用的物理连接每次都是不同的。还好，weblogic会帮忙重新创建有问题的连接。原因大概了解了，但这是谁的问题呢？ 为什么connection.close()不等存储过程的事务结束？

结论：一般而言，我们不建议通过JDBC调用存储过程的时候，在存储过程中定义事务，应该将tx的管理工作交给jdbc去做。 non-xa如此，xa亦如此，毕竟事务嵌套了以后，管理起来是个问题，完整性更是个问题。