[Fwd: Your proposal]

[Alastair Green <alastair.green@choreology.com>]

On behalf of Sazi, who has daytime access problems.

---

• From: "Temel, Sazi (MBS)" <Sazi.Temel@mortgagefamily.com>
• To: "'alastair.green@choreology.com'" <alastair.green@choreology.com>
• Date: Thu, 4 Oct 2001 10:04:33 -0400

Alastair and Peter,

I agree with you (and Mark) on not changing BTP's 2PO (two phase outcome)
protocol, and as it should be clear now that I do not propose a 3PO protocol
for BTP. Your proposal addresses my concern and is essentially what I was
also going to propose at today's conf call. If there is no FINAL_OUTCOME
request from the participants then the business is as usual, otherwise as
you suggested superior sends a FINAL_OUTCOME to those participants which
requested it. I think the only minor difference between your proposal and
mine would be that if CONFIRMED include a request to know the FINAL_OUTCOME
then I think the superior should send it, not optional; unless the
participant knows the intention of the superior it may end-up holding the
logs for ever..

Regards,
--Sazi

---------------------------//-----------------------------------------------
-
Dear Sazi, 
Peter and I want to propose the following in respect of your "3PC"
discussion. 
We are quite firmly opposed to modifying the fundamental process by which
the transaction outcome is decided. In other words we think that 2PC has the
right number of messages to achieve a coordinated decision. We agree with
Mark Little on that point. However, we can see value in the following, which
may align with your concern: 
	Add a parameter to CONFIRMED called "report hazard [or whatever we
called it on REQUEST_CONFIRM]" which can be T/F. 
	If the Superior is prepared to take this hint (it need not do so),
it will attempt to send a new message FINAL_OUTCOME with a contained HAZARD
(if there was one), or with no contents (if the final outcome equalled the
decided/intended outcome). 
	It is up to the Superior how this value is arrived at. Should the
information reflect the state of the entire tree, or only the immediate
Superior's branch? Should the Superior be allowed to ignore "unimportant"
failures? That is a matter for the implementation/application configuration,
and need not be dealt with in the spec.

We can certainly survey current issues (we will try to send a summary out
before the call). 
Yours, 
Alastair 
---------------------------//-----------------------------------------------
-

---

begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard