Transaction class design in Wishlist

[Pedro Lamarão]

In Wishlist we read:

         o Transaction support.  Create a "Transaction" class, an
          object of which you create on the stack, giving it a
          reference to the Connection object.  Transaction object's
          ctor calls a function on the Connection object to start
          a transaction set, and its dtor calls another function to
          commit the transaction.  Also provide a "commit()" member
          function, to commit before destruction.  This has a couple
          of uses.  First, it's useful for avoiding exceptions coming
          from ~Transaction(), if such a thing is possible.  Second,
          sometimes it's inconvenient to wait until the end of a block
          to commit the transaction, and adding artifical blocks is
          somewhat ugly.

My suggestion is to not "commit on destruction" like described above.
A transaction should not be committed if an exception is raised; it
should be rolled back.
Note how some implementations raise exceptions you should almost never
catch, like win32 raising "segmentation fault" exceptions.
The only way to commit the transaction should be through the commit()
member function.

A skeleton:

class Transaction {
public:

  Transaction ()
  : // allocate resources
  {}

  ~Transaction () {
    this->rollback();
  }

  void
  rollback () {
    // call C function
  }

  void
  commit () {
    // call C function
  }

private:
  // allocated resources
};