On 9. 7. 2018, Thomas Vandahl wrote: > On 9/6/18 7:03 AM, Thomas Fox wrote: > > 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? > > Yes, I agree - at least in the general case. I our case, however, > TorqueConnection is returned from our TransactionManagerImpl which > happens to *close* the connection right after commit.
I agree. In Torque's current usage, there is no need for handling operations
after commit or rollback. However, as the connection is passed to the user,
some users might be tempted to call rollback and commit on the connection
itself, and things will become strange then (no rollback on connection.close()
for example).
> I was thinking that probably the easiest way to handle the connection
> state is to rollback unconditionally before close. If work had been
> committed, no harm would be done. If not, we need to rollback anyway.
> WDYT? Do you have any idea of the performance implications?
Probably this will work in most cases. I'm not sure whether it will work in all
cases. I have no idea about performance implications though I suspect them to
be small.
Personally I like such behavior to be configurable for handling edge cases.
Another idea: Not TorqueConnectionImpl.rollback() and
TorqueConnectionImpl.commit() set the flag to not rollback on close(), but
TransactionImpl.rollback() and TransactionImpl.commit(). So in this case the
user can commit() and rollback() on the connection to his heart's content, but
only a call on TorqueConnectionImpl.commit()/.rollback()(which closes the
connection anyway) changes the connection close behavior. What do you think?
Thomas
smime.p7s
Description: S/MIME Cryptographic Signature
