Proposed resolutions of recent debates

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

Dear all,

I would suggest that the following issues are taken in the order shown as the agenda for the JavaOne meeting, with the expectation that WSDL and failure recovery will simply be assigned for written proposals, with the aim of discussing them at the London FTF.

Likewise, the message set draft should be treated as a working document which will be affected by all other debates. By the time of the London meeting we should aim to work through it systematically (will probably take one whole day of that meeting, as it is the core of the specification).

Alastair

* * *

The summary of current unresolved issues and proposed solutions reflects a discussion between Mark Little and me earlier today. We haven't had a chance to check each other's pieces -- I have sent it out to catch the end of the working day across the U.S. -- so we can't say it's jointly presented, but that's the spirit. The initials in [] are just there to tell you who acted as amanuensis.

Separately, Choreology will send out a revised draft protocol message set (by Peter) and a revised view of actors and roles (Alastair). The aim is that these will also align with the HP/Choreology consensus hammered(!) out over the last couple of weeks.

We hope this will give others a clearer view of the issues, so that the whole TC can come more quickly to firm decisions.

1. Coordinator timeout [ML]

Requirement

Tto have the ability to specify a lifetime (timeout) for a
coordinator such that if the coordinator has not been told to PREPARE before
this timeout expires, it will automatically CANCEL all registered
participants. This timeout value only has effect prior to PREPARE (or
CANCEL), and is ignored as soon as the coordinator begins to terminate. It
is assumed that this timeout is a relative value (probably specified in
seconds).

Benefit

There are two benefits to associating a timeout with the coordinator:

(i) a coordinator will not remain around forever if the initiator fails prior to calling PREPARE, using up resources - denial of service attacks, whereby the initiator creates lots of coordinators and deliberately does not terminate them, are also prevented.

(ii) if the timeout is passed in the transmitted context, then participants (and subordinate coordinators) can determine the status of the coordinator without exchanging messages [note, the fact that a participant could get this timeout is a more interesting slant than the OTS supports]. Once again, though, this timeout cannot be acted upon by any recipient (participant or subordinate coordinator) once it has been told to PREPARE. This has the effect that failures of coordinators do not keep resources around indefinitely (similar to the initiator failure argument above), and a
recipient can second-guess the action of a coordinator and CANCEL itself before an explicit CANCEL message comes downstream. In addition, a coordinator could use this information to implicitly assume that a downstream node has rolled back, and not send it a CANCEL message.

Implications

The timeout associated with the root coordinator must flow with the context. Recipients are allowed to modify this timeout value downwards to "take off" time spent, for example, computing before making subsequent downstream calls, i.e., the timeout value does not have to be a static readonly quantity, but it should never be greater than the initial value.

Issue: what does a 0 timeout mean? Do we want to have a "never times out" value and/or an "it's up to the coordinator to determine" value? I don't mind the latter as long as the value on the context is a relative value, e.g., if we assume 0 is provided at creation time to the coordinator and is up to the coordinator to determine what this actually means, the value that is put on the context should not be 0, or we lose the value of timeouts entirely. My temptation is to say that the timeout should be a positive value, greater than 0.

2. Implicit prepare [AG]

Proposal

A participant may send one spontaneous VOTE to its coordinator at any time prior to receiving a PREPARE . A coordinator can demand a VOTE by sending a PREPARE to a participant. A coordinator can send any number of PREPAREs to a participant. The values of all elements in the VOTE message can be set at will by the participant (i.e. can change on each successive VOTE).

Motivation

It may well be the case that a participant knows when it is prepared to VOTE independently of the coordinator. The one-shot optimization (appropriately indicated by initiator to service) is one such case.

The coordinator may require reVOTes because it wants to check on the effect of VOTE timeout qualifications. There are recovery scenarios where PREPAREs may be replayed, and where VOTEs may be replayed.

3. VOTE/"ready" timeout qualifications [AG]

Proposal

Supplement the Mt Laurel decision by modifying the timeout qualification on VOTE/"ready".

a) Clarify interpretation of timeout value to mean "at least <timeout> seconds".

In other words a VOTE/"ready"/"cancel"/100 means "I will abide by the coordinator's outcome if I receive the outcome message within 100 seconds. At any point after 100 seconds has expired I may act as if I have received CANCEL. I will never autonomously act as if I have received CONFIRM".

b) At present the timeout qualification contains two elements: one a choice indicating cancel or confirm, the other the timeout interval. Add a third element, which would indicate to the coordinator whether or not the participant requires outcome notification. Outcome notification is always acknowledged, to allow log clean-up.

c) Add a third value, "active" to the first element (in addition to "cancel" and "confirm").

Motivation

The outcome notification flag allows the participant to decide whether it needs to be told what the overall outcome was. This allows a useful optimization. When the participant's declared default (timed-out) outcome is the same as the final outcome decided by the coordinator there is no fundamental need to send the outcome to the participant. The coordinator can forget the participant. If the participant is going to be "eager", and attempt to cancel (or confirm) very soon after the timeout has expired then it is not interested in learning the outcome: it just wants to take its autonomous action and forget the coordinator. On the other hand, if the participant is guaranteeing 1000 seconds, but will in fact hold the resource for longer (perhaps because there is no contention for it), then the outcome notification can be acted upon, say after 1250 seconds. Or the coordinator can re-PREPARE with some hope of getting a positive re-VOTE.

If a participant times out then it may undertake to cancel, to confirm or to go back into active phase after some period, to allow further work to be done for this transaction.

4. Open-top coordinator [AG]

Proposal

The coordinator presents a participant-like interface to its superior (the initiator or the composer). The superior sends PREPARE to the coordinator, and receives back a VOTE. If the VOTE is "ready" then the superior can send either CANCEL or CONFIRM to the coordinator.

Motivation

We want close control by the application over the final outcome of a coordinator. The fact that an atom is prepared does not mean that we wish it to confirm automatically (unlike conventional transactional demarcation APIs). See next point on composer-coordinator relationship.

5. Composer-coordinator relationship [AG]

Proposal

The upper (application-facing) interface of the composer is undefined (decision of Mt Laurel). The relationship between a composer (of a cohesion) and the coordinator (of an atom) is a) the relationship of an initiator to a coordinator, b) the relationship of a coordinator to a participant. In other words, an atom can be effectively enrolled in a cohesion (which may happen as late in its life as the point where the cohesion sends a PREPARE). In order to establish this relationship the composer needs to send its CONTEXT to the coordinator. This allows the coordinator to discover its outcome in the event of crash recovery; it cannot do this in relation to an initiator.

(Initiators are non-persistent superiors, which do not record durably their decision, leading to default cancellation after a crash; composers are persistent superiors, which can be contacted for outcome after a crash).

[The nature of a composer CONTEXT has not been discussed or properly defined. It is likely to closely resemble a coordinator CONTEXT, containing address and an id, and possibly a timeout. It is quite possible that it is indistinguishable in its fields and potential values.]

Motivation

A cohesion, relating to one to many coordinators with "open tops", can juggle the membership of the ultimate set of atoms to be confirmed. The cohesion can take into account failures of some atoms, and the application meaning of readiness on sets of atoms, to freely decide when and how to confirm and cancel all the atoms it takes control over.

6. Compound Messages ("Boxcarring") [AG]

Boxcarring is a working title for that which is required to satisfy the demands of "one wire", "one-shot and other optimizations" and "context augmentation of application messages (infection, implicit context propagation)".

Proposal

Our consensus is that the full facilities described in the mail that I sent out a couple of days ago are needed. This described a possible scheme:

"The most general view that spans all three is that the BTP protocol should
permit the creation of compound messages, directed to A(X) -- address of X --
where each element is a message (let us say, {1, 2, 3}) with an address, e.g.
A(1).

In this case an app request + CONTEXT going to A would be, using a convention
that {1,2,3 ...n} = compound message, and -- = "destined for address":

{*REQ* -- A, CONTEXT -- A}-- A

A forwarded message (for one-wire) would look like:

{ENROLL -- A} -- X

A boxcarred message (for optimization) might look like:

{ENROLL(Pa) -- A, VOTE(Pa) -- A, ENROLL(Pb) -- A, VOTE (Pb) -- A) -- A

and a natural optimization in the first and last cases might be to allow the
internal addresses to be omitted if they were the same as the first receiver,
e.g.

{ENROLL(Pa), VOTE(Pa), ENROLL(Pb), VOTE (Pb)) -- A

{*REQ*, CONTEXT}-- A"

It is necessary for all implementations to be able to receive such compound messages. It is not required that an implementation is able to, or does, send such messages.

Motivation

It is possible to draw up "capability levels" (no compounding, implicit propagation only, etc). However, it seems very complicated to attempt to define those levels in a precise way. As the requirements for compounding seem strong, it makes most sense to demand reception capability.

[The trickiest part of compounding is to deliver multiple messages to different addresses, which is necessary for "one wire". This requires careful examination of the role of "interceptors". A better name for this role is needed, which escapes the narrow implementation implication of filtration.]

7. Actors and Roles [AG]

TBS over the weekend

For London FTF to discuss fully:

8. Failure recovery and message redirection [AG]

No complete written presentation has been made on this topic. The proposal is that this be assigned to a volunteer at JavaOne FTF, and discussed fully in London.

9. WSDL [AG]

There are three discussion points on WSDL:

a) its use (or otherwise) in presenting the protocol in the specification
b) its use as a potential carrier binding
c) the issue of dependency (if any) upon WSDL

10. Message set [PF]

See separate message coming today from Peter
 
 
 
 
 

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