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
>implementation".

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?

   Thomas

Mime
View raw message