On 03.09.18 05:32, Thomas Fox wrote: > As I understand it, TorqueConnectionImpl.committed and > TorqueConnectionImpl.rolledBack keep track of whether there could be > outstanding operations in a transaction. So when one calls close() on a > connection with uncommitted changes these get rolled back. But what if one > calls commit() and then does other operations on the connection? As I > understand the javadoc of java.sql.Connection, this is legal (maybe I'm > wrong). But the current logic in TorqueConnectionImpl would not do any > rollback on close() then.
I will have to check what the contract actually is. The implementation right now is more or less a 80% solution. > And does TorqueCoonnectionImpl keep the contract of > java.sql.Connection.close()? It says in > https://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html#close()that > close() would release all resources, but TorqueConnectionImpl does more > than that. However, I know other frameworks, e.g. Connection pools, which do > other stuff on close() to guarantee a clean connection, but personally I'm > not happy about that either. Actually, the standard contract of a JDBC connection is already bent badly by all connection pools that I know. I think we are not worse. > Just a not-well-thought-through idea: Perhaps one can solve some of these > issues if TorqueConnection would not inherit from java.sql.Connection, but > would be a different object wrapping a java.sql.Connection, with a different > contract, like: My goal was to change as little as possible in the rest of the code. If we introduce our own connection object, all signatures of our methods taking java.sql.Connection must be changed. I see advantages and disadvantages in this approach. I just didn't want to get into it. Bye, Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
