Re: [boost] [transaction] New Boost.Transaction library under discussion

Subject: Re: [boost] [transaction] New Boost.Transaction library under discussion
From: strasser_at_[hidden]
Date: 2010-01-23 22:58:08

Zitat von Bob Walters <bob.s.walters_at_[hidden]>:
> Stefan,
> IIUC, you are essentially proposing we implement resource managers per
> the XA standard, correct?
> (http://www.opengroup.org/onlinepubs/009680699/toc.pdf)  I'm basing
> this on your previous reference to BerkeleyDB's XA APIs.
>
> How far do you intend to go with ensuring the recoverability of these
> multi-resource transactions?  Specifically,
> The XA standard requires that RMs persist the state of the transaction
> during prepare() so that the transaction can still be completed or
> rolled back, consistently across all RMs even if the two-phase commit
> is interrupted by process failures.

I haven't read much of the XA standard, but I guess it's pretty much  
the same thing.

you also use write-ahead redo-logging, don't you?

so what the RMs need to do is split up the commit in 2 phases with a  
prepare message written to the log at the end of the prepare phase,  
and change the recovery process a bit.

right now when the log is read a transaction is replayed based on if  
there's a commit message or not. when there is a prepare message (but  
no commit or rollback) the RM needs to report that to the TM through a  
function like recover() and then the TM decides if that transaction  
ought to be replayed or rolled back.

  The TM itself must have some form
> of persistent storage to track the state of all such transactions, for
> recovery processing.  Am I understanding your intention correctly?
>

yes, I've been referring to that by "distributed transaction log".  
it's a quite simple log that contains commits messages for distributed  
transactions and a list of the IDs of the resource transactions for  
each. at least in my mind, I haven't implemented any of this.
basic_transaction_manager throws if more than one RM took part in the  
transaction.