[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: working copy storage for RA properties

From: Bill Tutt <billtut_at_microsoft.com>
Date: 2000-12-07 01:34:21 CET

From: Jim Blandy [mailto:jimb@zwingli.cygnus.com]

> Bill:
> Do we care? Even if we think we care, do we care enough to do the
necessary
> 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:
Phase 1:
T's coordinator asks all participating resource managers (RMs) to "prepare
the transaction". The RMs replies "prepared" after the T's updates are
Durable.

Phase 2:
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
abort.
Participants acknowledge the work has been done by replying "Done" back to
the coordinator.

There are a lot of annoying details that fall out of this simple concept
though.

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)

Bill
Received on Sat Oct 21 14:36:16 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.