Subject: Re: [boost] [transaction] New Boost.Transaction library under discussion
Date: 2010-01-23 22:58:08
Zitat von Bob Walters <bob.s.walters_at_[hidden]>:
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk