Boost logo

Boost :

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?
> ( 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, gregod at, cpdaniel at, john at