Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!hplabs!hpda!hpcuhc!dhepner
From: dhepner@hpcuhc.cup.hp.com (Dan Hepner)
Newsgroups: comp.databases
Subject: Re: two phase commit ???
Message-ID: <2060020@hpcuhc.cup.hp.com>
Date: 24 Jun 91 18:01:49 GMT
References: <1991Jun23.191959.29921@logixwi.uucp>
Organization: Hewlett Packard, Cupertino
Lines: 41

From: rcr@logixwi.uucp (Rainer Ruppert)
>scenario:
>
>	Three systems a,b,c where a is the coordinator b,c are the agents
>	managing two tables which are under update operation.
>
>	The coordinator is doing the phase one and after completing it, phase 
>	two. Phase two is completed on b and c, but the final quit (ack) from
>	c could not received by the coordinator because the network dropped it
>	while a millisecond of blabla... .
>	
>	System c is releasing the locks and the local actions on that system 
>	are able to manipulate the c-local table, while the coordinator a
>	is rejecting the transaction on a and b.
>
>	The database is corrupted-or ???

Two phase commit is absolutely guaranteed to keep distributed
databases synchronized.

Check out a description of two phase commit a little more.  Once phase
1 is completed, the coordinator logs that fact, and with that log the 
fate of the transaction is sealed (committed).

In the example posted, the transaction is not rejected by A and B, and
indeed this situation is solidly addressed by 2PC.  B has no need to be 
informed of the loss of C.  When C does return, a recovery protocol will 
establish to A that C indeed finished the transaction.  Should the
comm error have happened on the way from A to C, the recovery protocol
would have advised A that the transaction had indeed committed.

The only irritant with 2PC is that it is subject to "getting stuck",
when say B acknowledges phase one commit, and C receives the phase 1 
commit but does not respond, perhaps having caught fire, but perhaps 
just having it's phone line down.  The 2PC protocol is stuck waiting for
C to respond, and cannot time-out to a decision without the potential 
for inconsistency.  A system administrator (or automation thereof) may 
in this case make decisions which override the "stuck" two phase commit, 
and such overrides have the potential to create inconsistency. 

Dan Hepner