List:MySQL++« Previous MessageNext Message »
From:don thompson Date:March 6 2006 8:51pm
Subject:Re: Transaction class design in Wishlist
View as plain text  
Hi,
My work with a transaction class is too specialized for what you're
looking for, but may have some useful ideas to
consider.  My implementation is basically a banking account, and
implements the commit as a function called upon
'no exceptions' as mentioned.
Consider for example the posting of a check to your checking account,
which has an overdraft line of credit.
The transaction begins as a {Withdrawal Check}, fails due to
insufficient funds, and throws exception  NSF.  This failure
is caught, which causes addition account analysis.  The account has an
OD Protection record, so the input transaction
stream is changed to {ODTransfer, Withdrawal Check}. 
Lets consider some outcomes of posting this transaction: ODTransfer =
{Credit Line Add-On, Deposit to Checking}
for the NSF amount from first attempted post.    The Add-On may fail due
to insufficient remaining line, which therefore
throws an NSFLine exception.  This once again causes additional account
analysis, for example a second source of funds
might be from another deposit account such as savings. 
The transaction stream is modified to include this transfer.  This type
of transfer may fail to to excessive transfers during
the month (US Banking regulation), and throw an appropriate exception.
My point is, the transaction class knows how to build the sequence of
transactions in an attempt to satisfy the  base
transaction.  Posting attempts at these complex transactions either
succeed (then commit) or fail (throw exception).  Once
the sequence of account rules are exhausted, the transaction fails with
a final exception.  In the above, I forgot to mention
that at each failure (exception thrown), a rollback is called, so that
the fresh attempt at the revised transaction can be
attempted.
Again, I know this is a very application specific example, but it really
shows how a transaction class, together with exceptions,
rollback and commit can make a very elegant solution to a very complex
problem.
I'm very interested in how this (your) transaction class develops.

Don

Pedro Lamarão wrote:

>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
>
>
>
>  
>

Thread
Transaction class design in WishlistPedro LamarĂ£o6 Mar
  • Re: Transaction class design in WishlistWarren Young6 Mar
    • Re: Transaction class design in WishlistPedro LamarĂ£o6 Mar
      • Re: Transaction class design in WishlistWarren Young6 Mar
      • Re: Transaction class design in Wishlistdon thompson6 Mar
        • Re: Transaction class design in WishlistWarren Young6 Mar
          • Re: Transaction class design in WishlistWarren Young6 Mar
  • Re: Transaction class design in WishlistDrew Vogel8 Mar
    • Re: Transaction class design in WishlistWarren Young8 Mar