Zitat von Bob Walters <bob.s.walters@gmail.com>:
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.