OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Coordinator timeouts (was Re: Managers, addressses and the like)


Mark,

I agree with your substantive point on the nature of coordinator
timeout. It does not mix well with participant timeouts, on reflection.

I have some questions and issues, however.

I presume that the coordinator timeout is transmitted in the CONTEXT,
and that it is in some way communicated to participants. I presume that
services that forward the CONTEXT are allowed to trim the timeout to
avoid excessive prolongation (minor point).

Here's where it gets a little less obvious. If a participant gets the
timeout and it expires then it is only advisory: if the participant is
happy to hang around and hold resources after the expiry, that is its
business. It will never go wrong, get a wrong result. It could decide to
send an INFERIOR_STATUS to the coordinator, and get back an Active
status, in which case it might decide to hang on. If the status messages
included a timeout value then it could receive an updated timeout. In
other words, this coordinator timeout could be viewed as a hint (can't
really be viewed as anything else).

* * *

The minutes from Mt Laurel are accurate. The decision concerned
participant timeouts, and is accurately recorded. The point that you
raised there on participant timeouts, which was agreed to, is also
recorded, namely that the PREPARE can be qualified with a "minimum upper
bound" on the participant timeout, sent from the Coordinator to the
Participant.

There was no decision or concrete proposal about coordinator timeouts.
It was mentioned in discussion, but mentioning things doesn't make them
decisions, nor did the minutes attempt to record every issue that was
mentioned. Every thing I minuted as agreed was read over to the meeting
before a vote was taken, and before I noted it, sometimes verbatim,
sometimes very close to verbatim when we hadn't arrived at the
absolutely precise wording.

A side comment on participant timeouts: I think that you will not avoid
the need for failure recovery in participants by participant timeouts,
if that is what you have in mind. Also, the motivation for participant
timeouts is that a coordinator should not be able to wrest control of
time-sensitive data or locks from its owner. Denial of service is only
one special case of this. Expiry of offers is actually a much more
likely use, in my view.

Alastair
begin:vcard 
n:Green;Alastair J.
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
adr:;;13 Austin Friars;London;;EC2N 2JX;England
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
fn:Alastair J. Green
end:vcard


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC