Re: Boxcarring and its implications (was Re: Open-top coordinators andprotocol)

[Mark Little <mcl@arjuna.com>]

> Isn't it true that the "single wire" approach *requires* standardized
> interception, in the sense that messages for A must pass through X?
(Doesn't
> require boxcarring, I agree).

Yes.

> Isn't it also true that the network optimization described as one-shot
> *requires* boxcarring, otherwise you do end up with 6 instead of 2? (Or a
worse
> ratio if number of participants > 1)?

Yes.

>
> And lastly, isn't it true that implicit propagation *requires* some kind
of
> bundling of messages (qualification is one view)?

Yes.

> If you combine these requirements (and this is first and foremost a
requirements
> discussion, not a "how do we do this in the protocol" discussion) then I
think
> you end up with one approach, that I favour (mandatory interoperable
boxcarring
> and message forwarding). If you chip away at these requirements you may
end up
> with something much more minimal.

Actually I think what we have been arguing about boils down to the
definition of mandatory. If you take the position that it *must* always been
done, then I'm against that. However, if you take the case the it *may* be
done if required, then I don't have a problem with that. It still requires
the intelligence to do it though.

Take the case of interposition in the OTS, for example. Here you can delay
the register_resource call on the interposed coordinator by piggybacking the
information that a subordinator coordinator has been created in the returned
context. In the meantime though, the application response can be fielded,
and the work performed, nominally in the context of the interposed
transaction, in the assumption that the return response will succeed in
enlisting the interposed coordinator. However, if this fails, then all the
work done by the original recipient will have been useless and rolled back.
So, in some situations I may very well want to try to do the
register_resource immediately and only do the application work if that
succeeds. A protocol that allows both has its merits.

> 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).

Permit is probably the right word here, as it (at least to me) implies that
it doesn't have to be used.

Mark.

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