Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.databases
Subject: Re: two phase commit ???
Keywords: commit in distributed systems
Message-ID: <1197@tetrauk.UUCP>
Date: 24 Jun 91 13:52:04 GMT
References: <1991Jun23.191959.29921@logixwi.uucp>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Distribution: comp
Organization: Tetra Ltd., Maidenhead, UK
Lines: 56

In article <1991Jun23.191959.29921@logixwi.uucp> rcr@logixwi.uucp (Rainer Ruppert) writes:
>Hi Networkers,
>
>yesterday a friend of mine, edp-manager, said: "The last week the salesman
>of all the big database companys joined me. Most of them wanted to sell the
>*two phase commit* for our new distributed system, but I could not believe that 
>the tpc is really able to make distributed systems recoverable."
>
>At first, I remebered Ceri & Pelagatti and Date and told him, be sure, its save.
>But seconds later I wasn't quite that sure then before. Let us suppose following
>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 ???

The key requirement for reliable two-phase commit (2PC) is that the precommited
state must be stored in non-volatile form on all participating systems.  When a
system accepts a precommit request, it is _guaranteeing_ that it will not fail
to fully commit, under any curcumstances, although it is still able to abort if
requested.  This guarantee should be able to survive the scenario where the
system goes down between precommit and final commit, requiring that the
local database be rebuilt from transaction logs.  The precommitted state is
itself logged in the database.

Consequently, the transaction coordinator must be able to continue attempting
to secure a full commit indefinitely, which means that it also stores the
transaction state in non-volatile form.  It must certainly not be susceptible
to low-level protocol glitches.

2PC relies on getting to points of no-return.  A participating system gives up
the right to force an abort when it accepts a precommit.  The coordinator
cannot request an abort once it has started the full commit sequence.  If at
this point contact fails, then it just goes on indefinitely attempting to
reconnect, and secure the full commit - it has no other choice.

You will probably find that in most implementations, the precommit action
performs the database updates, while keeping enough information in the logs to
allow the action to be undone if required.  Only very occasionally will a
successful precommit be followed by an abort request from the coordinator.

-- 
Rick Jones, Tetra Ltd.  Maidenhead, Berks, UK		rick@tetrauk.uucp
Chairman, NICE (Non-profit International Consortium for Eiffel)

Any fool can provide a solution - the problem is to understand the problem