Author Topic: Abort This  (Read 7163 times)

0 Members and 1 Guest are viewing this topic.

owenwengerd

  • Bull Frog
  • Posts: 451
Re: Abort This
« Reply #15 on: March 02, 2013, 11:10:17 AM »
I think you make a valid point about Abort using the same underlying code as Commit, but in my opinion there is (or should be) a *logical* distinction at least, even if the implementation shares code under the hood. I view a transaction as a single atomic "action". From that perspective, the logical purpose of Abort is not to roll back changes per se, but to prevent them ever occurring. The fact that under the hood this is managed by actually making the changes one by one, then rolling them back in Abort, should be an imnplementation detail. I think logically, system state changes that are side effects of (or "belong to") the transaction should participate in the transaction model -- but I don't think wheel zooming, for example, "belongs" to the transaction.

In any case, I think we agree that Abort is not the logically correct way to end a read-only transaction, even if in practice an Abort perhaps ends up behaving identically to a Commit. A transaction, whether writes occurred or not, should be aborted when something prevents its successful completion such that all the changes and side effects that belong to the transaction are never (logically) performed.

My concern about Fenton's response is that I sensed a willingmess to ignore the logical purpose of Commit and Abort in favor of "just making it work".