db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fox <thomas....@seitenbau.com>
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 Thu, 06 Sep 2018 05:03:27 GMT
On 05.09.18 19:30, Thomas Vandahl wrote:
> 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

Ok, but should we not reset the committed and rolledBack Flag when the user could have issued
further statements after a commit/rollback, e.g. when connection.createStatement() ist called?


View raw message