Warren Young escreveu:
> Pedro Lamarão wrote:
>>
>> 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.
>
> Good point. I'll keep it in mind.
>
Here you go:
--- Wishlist 2005-11-02 17:13:20.000000000 -0200
+++ Wishlist.new 2006-03-06 17:06:01.000000000 -0300
@@ -29,18 +29,16 @@
base class.
- 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.
+ o Transaction support. Create a "transaction" class in the stack,
+ initialized with the Connection object,
+ so that it can call a function on the Connection object to
+ allocate a transaction set.
+ A Transaction may act as a "container" of actions to be committed
+ with a commit() member function call.
+ The transaction will only be committed through a call to this
+ member function; if the destructor is called on an "active"
+ transaction, it is rolled back. This is particularly useful
+ if an exception is raised.
o Add a configure script option to allow the new lock
mechanism to use platform mutexes via the Boost.Threads
