Re: 2001-06-01_OASIS_BTP_abstractmessages_DRAFT_1

[Mark Little <mcl@arjuna.com>]

BTW, thank goodness the document has line numbers :-)!

> page 4, line 1. To-be-propagated flag: is there a requirement for
> "must-be-propagated" and "may-be-propagated"?
> We could make the flag tri-valued: effectively must, must not, may.  But
> the flag really only makes sense if the receiver doesn't understand the
> qualifier - in which case how can it decide what to do on "may".  If it
does
> understand the qualifier, I would expect it to be able to override the
> to-be-propaged flag if it feels like it (on the grounds that is then
> composing its own similar, but different message and is asserting that
this
> new message is correct and appropriate). Should that be explicit ?

I think the only concern here was on the wording: "... if this has the value
"yes" and the receiving entity passes the BTP message ..." implies that it
doesn't have to. If this is the intention then I'd just like it to be more
explicit.

> page 4, line 5: To-be-propagated=no: Does this mean "either propagate this
> as is or propagate nothing", or "either propagate this as is or propagate
> your own data in its place"?
> I meant it to mean drop this qualifier. That wouldn't prevent another
> qualifier being sent on an outbound message. Conceivably, even one with
the
> same value but generated by this entity. (c.f. CORBA contexts like
two-way,
> which certainly should not be blindly propagated, but could appear on
> propagating messages, though applying to a different subject)

Agreed.

> page 12, line 32: If the coordinator gets CONFIRMED (see below) then there
> should be no requirenment on it to keep information on that specific
> participant, so if there is a recovery scenario where the coordinator
> crashes and recovers, this participant won't see another CONFIRM message.
>
> Not sure where the "see below" referred to.

Neither am I now ;-)

> Actually this isn't quite right
> on several counts - it won't necessarily be CONFIRM, but SUPERIOR_STATUS
> that gets resent; as you say, it might or might not get sent depending on
> how the coordinator deals with the information; if the participant makes
an
> autonomous confirm decision (usually because it's timeout fired),
CONFIRMED
> will get sent before the CONFIRM arrives - and there can be a CANCEL and
> CONTRADICTION too.  Once the state tables are finalised (and agreed), I'll
> go back through the abstract messages and ensure the text aligns.

What I meant was that once the participant has seen the entire termination
protocol it can go away. If the coordinator had infact just failed before
receiving CONFIRMED there's the possibility it may resend SUPERIOR_STATUS
and find the participant has vanished.

> page 13, line 19: Why would a participant send an UnknownSubordinate
> message?
>
> ? it would be the coordinator that returns an UnknownSubordinate FAULT on
> receiving an inexplicable CONFIRMED.  It shouldn't have happened.
Something
> is broken.

OK, I was reading the message sender wrongly.

>
> page 14, line 13: state table sequences ensure that the "contradiction" is
> certain to be known to the superior (which can then pass it on up), with
one
> exception: if the superior cancels, and does not persist any information
> (which is its right under presume abort),

It can only cancel without causing a heuristic if it hasn't received a
prepare. That is within the presumed abort protocol. Autonomous cancel after
prepare is into the domain of potential heuristics, which was the point of
my comment in the document.

> and there is a failure, the
> subordinate will know there was a contradiction but there may be nothing
at
> home at the superior to tell. (This also occurs with both OTS and OSI TP -
> hence heuristic hazard).

See above. Heuristics can only occur if the participant has received a
prepare. A participant (e.g., an OTS Resource) cannot arbitrarily commit
unless it has first received prepare. It can arbitrarily roll back before
prepare without causing heuristics, but once it has prepare a roll back is
different.

> Perhaps we should add a "contradiction" flag to
> INFERIOR_STATUS to ensure this case can at least be sent to the superior
(or
> its manager). In other cases, CONTRADICTION acts as a "forget" message.
>
> page 15, line 27: See message coming up, but I'd like it to be possible
for
> a non-participant to determine the status of a "transaction".

I don't have a problem with this, and it does tie into something I said
later in the document.

> So does Alastair :-)  Would it just be status, or are there possibly other
> management-type messages needed ?

We could have an entire specification on management interfaces ;-) I'm happy
with using status.

>
> page 16, line 8+ : A coordinator can never return Confirmed? Are we
> therefore assuming tha ...
>
> I hadn't fully thought these through - should be clearer once the state
> tables are done. Yes, Confirmed is possible, at least for the general
> "GET_STATUS" reply. But a participant wouldn't have sent CONFIRMED until
it
> was sure, so it wouldn't then ask, as you say.
> Issue ABSMSG-003: add a get_status message and define reply

Actually I was thinking more about a non-participant simply requesting the
status of the transaction.

> page 16, line 31: But this is insufficient to differentiate between
> Confirmed and Cancelled.
>
> if Inaccessible is received, the other side keeps trying - its just a
> protocol-level way of saying connection failure. Unknown (from a superior
to
> an inferior that in doubt) can always be taken as cancel.

Agreed, but not to an external observer. I too would like it to be possible
for a non-participant to determine a transaction outcome, e.g., a
non-transactional audit trail system.

>
> page 18, line 17: However, if one side is cancelled then the result is
> different.
>
> but this concerns only where they are both active (i.e. uncancelled). Some
> protocols (OSI TP at least), will trigger rollback if there is a recovery
> attempt when one side is active.

OK.

Mark.

----------------------------------------------
Dr. Mark Little (mark@arjuna.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203