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:30:53 GMT
On 05.09.18 19:19, Thomas Vandahl wrote:
> 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.

The Javadoc of close() actually says:

It is strongly recommended that an application explicitly commits or
rolls back an active transaction prior to calling the close method. If
the close method is called and there is an active transaction, the
results are implementation-defined.

As I read it, this gives us some freedom in the "definition of our
implementation".

Bye, Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Mime
View raw message