db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Vandahl ...@apache.org>
Subject Re: svn commit: r1839284 - in /db/torque/torque4/trunk: torque-runtime/src/main/java/org/apache/torque/ torque-runtime/src/main/java/org/apache/torque/oid/ torque-runtime/src/main/java/org/apache/torque/util/ torque-runtime/src/test/java/org/apache/torque/...
Date Wed, 05 Sep 2018 17:19:19 GMT
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-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message