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
smime.p7s
Description: S/MIME Cryptographic Signature
