RE: [bt-spec] Votes for 13 March call

[Peter Furniss <peter.furniss@choreology.com>]

On a couple of Doug's points:

> -----Original Message-----
> From: Doug Bunting [mailto:dougb62@yahoo.com]
> Sent: 14 March 2002 20:26
> To: Furniss Peter; Pope William Z
> Cc: bt-spec@lists.oasis-open.org
> Subject: [bt-spec] Votes for 13 March call
>
>
> Votes for myself, Doug Bunting, the one sending this message, et cetera.
> (Should be fairly obvious since OASIS process doesn't support proxy
> votes).
>
> - Issue 29: Redirection
> 	AGAINST - current proposal adds value by providing the "carrier
> protocol" option for REDIRECT but complicates the situation by adding
> the FAULT/redirect.  Changes as they stand do not explain REDIRECT
> versus FAULT/redirect clearly.  When a request / response message (such
> as PREPARE / PREPARED) travels over the Superior:Inferior relationship,
> why can't the receiver respond with Fault/redirect?  On other
> relationships, if the receiver has the address of the sender, should
> they also send a REDIRECT message?

PREPARE/PREPARED aren't strictly a request/response pair as understood in
the spec. The definition of btp request/response pair is that the request
has a "reply-address" parameter - so PREPARE is not one. (This gets modified
a bit by issue 96, but I've been drafting text today that keeps the
"reply-address" rule)

> 	In general, why are there two mechanisms to carry the same
> information?  This "feels like" creating a new message to cover the
> difference between a PREPARED message sent to register an autonomous
> decision versus one sent in reply to PREPARE.  Allowing REDIRECT
> (explicitly or implicitly using the new and good carrier protocol
> option) to be used in reply seems much cleaner.

The FAULT/redirect is used where the REDIRECT cannot be used pre-emptively
because the moved entity doesn't have an address for the future sender of
what will be a mis-directed message. (hope that sentence is clear !). We
could have re-used REDIRECT as the response instead of FAULT, but it
complicates several things - REDIRECT then gets a load of parameters that
are only there conditionally.

We could use the FAULT as the response on the Superior:Inferior
relationships when it is reply to a misdirected message (which would include
both PREPARE and PREPARED for example), but we would still need REDIRECT as
a "change of address" postcard (often sent pre-emptively on a carrier
request from the *new* address).

So it's FAULT/redirect to Initiator, Terminator, Status Requestor, Enroller,
REDIRECT to Superior and Inferior

> - Issue 99: PREPARE_INFERIORS and FAULT(InvalidInferior)
> 	FOR B (PREPARE is an intermediate state and doesn't imply
> the overall
> transaction will be confirmed or cancelled, why worry about
> implementations choosing to optimistically PREPARE various inferiors?
> Disagreements between the Terminator and Decider on the valid inferiors
> don't always indicate application errors.  This situation is made more
> common because RESIGN isn't forwarded to the Terminator.  Only the
> Decider forgets about resigned inferiors.)
> 	caveats - This issue closes most of the problems described
> but worsens
> the problem we encountered with CONFIRM_TRANSACTION/report-hazard and
> PREPARE_INFERIORS/report_hazard (issues 50 and 107).  The proposed text
> doesn't prevent the Decider making a Cancel decision due to invalid
> inferior identifiers and doesn't describe handling of errors encountered
> contacting a particular inferior "known" to the Decider.

Nor should it. A Decider always has the right to make a cancel decision
(until and unless it makes a confirm decision (after CONFIRM_TRANSACTION and
receiving appropriate PREPAREDs)), due to internal or other problems.

> 	If a Decider chooses to cancel based on encountered errors
> or received
> FAULT messages (including invalid inferiors), are FAULT messages sent to
> the Terminator?  What changes when report_hazard is "false"?  (I think
> report_hazard determines whether HAZARD messages are sent but doesn't
> affect FAULT messages but want to be sure.)

No - FAULT only means "the message you just sent me was wrong". If the
Decider cancels after CONFIRM_TRANSACTION, it will reply with
TRANSACTION_CANCELLED if all goes smoothly or if report-hazard if false,
INFERIOR_STATUSES if there are received HAZARDs or contradictory (confirm)
autonomous decisions.

report-hazard just means "I do/do not want to be told if decision made by
the decider is contradicted". For some applications it would make no sense
to be told, because they are out of the loop at this point and can't do
anything about it - the Decider might be logging the hazard case to
management mechanisms anyway. For other applications, they do want to be
told, hence the flag.

> 	For the second problem, think of crashed inferiors.  The Decider and
> Terminator agree on the valid inferiors list but don't know about a
> particular inferior's failure.  So, are errors encountered contacting
> known inferiors during the PREPARE phase of CONFIRM_TRANSACTION handled
> through HAZARD, FAULT/InvalidInferior or something else?  What changes
> when report_hazard is "false"?  Part of this may be answered by
> requiring a decision be made prior to sending PREPARE but that prevents
> some common 2PC implementations and invalidates our current
> PREPARE_INFERIORS followed by CANCEL_TRANSACTION option.

If an attempt to send PREPARE fails, or it seems to be taking a long time to
get a PREPARED or other response back, the Decider can choose to resend
PREPARE (this is actually an active-phase recovery, but we don't have
different messages) or can give up and decide to cancel that Inferior. It
can try resending for a bit, then give up. If/when it does decide to cancel
the Inferior, it can then report this to the Terminator (with
INFERIOR_STATUSES) if this is a cohesion and the trigger was
PREPARE_INFERIORS or must set the whole transaction to cancel if the trigger
was CONFIRM_TRANSACTION (because the confirm-set is then locked, even for a
cohesion)

If the crashed inferior had not persisted any information (and if it hadn't
prepared it may or may not as far as BTP specifies), but then comes up, the
PREPARE will be replied to with an INFERIOR_STATE/unknown, which the Decider
will treat as equivalent to CANCELLED. If it had persisted, then, when
restored it replies with PREPARED (with any luck), and it was only a
temporary problem after all.

(If the delay in getting through to the Inferior takes the Decider past the
transaction timeout, it could decide to cancel everything even on a
PREPARE_INFERIORS, since there won't be time now to get CONFIRM_TRANSACTION.
But, as I said, the Decider always has the right to cancel if it wants to)

Some of this is covered in the model draft.

Peter