From: Jim Blandy [mailto:email@example.com]
> Do we care? Even if we think we care, do we care enough to do the
> 2 phase commit footwork?
> [Wearing journeyman hacker hat] Wow! How does it work?
Well, just remember, you asked... :)
Just a little brush up about transactions first though:
Transactions need to satisfy the ACID test:
* Atomicity - All or nothing, partial results are not allowed.
* Consistency - preserve data integrity
* Isolation - execute as if they were run alone
* Durability - results aren't lost by a failure
Now, having a distributed system obviously makes ensuring atomicity much
harder. The solution to this is the two-phase commit protocol. The main idea
is to have all "resource managers" save a Durable copy of the transactions
work before any of them commit.
If one resource manager fails after another commits, the failed system can
still commit after it recovers.
The actual protocol to commit transaction T:
T's coordinator asks all participating resource managers (RMs) to "prepare
the transaction". The RMs replies "prepared" after the T's updates are
After receiving "prepared" from all participating RMs, the coordinator tells
all RMs to commit.
If it receives "No" votes from ANY RMs, the coordinator tells all RMs to
Participants acknowledge the work has been done by replying "Done" back to
There are a lot of annoying details that fall out of this simple concept
The participant MUST NOT do anything until the coordinator tells it to
commit or abort the transaction.
This is its "uncertainty period". That means that it must retain any locks
that are owned by the transaction.
Even after a participant restarts (and recovers after a failure), any
transactions in an uncertain state are still uncertain.
And a bunch of other nasty cases that create havoc. :(
Apparently, Berkeley DB looks like it supports being a local transaction
manager, so you're half way there. ;)
(DbTxn::commit from the C++ API)
Received on Sat Oct 21 14:36:16 2006