Re: [bt-spec] Re BTP Issue 103 (was issues 100, 101, 103 and 105)

[Mark Little <mark_little@hp.com>]

> The existing specification text is implementable, and produces a desired
> behaviour which helps to enforce transactional integrity.

I would hope so given the effort expended so far. However, our proposed
change would not affect this at all - if it did then I would certainly
consider removing it or at least leaving it to later.

> It can, at some level, be reasonably criticized: you could make a case for
> splitting CONTEXT into ENROLLEE and CHECK, and renaming CONTEXT_REPLY to
be
> CHECK_REPLY. Then you would never see checking info (i.e. the reply
address) in
> ENROLLEE, and explicit control over checking would become possible (send
> ENROLLEE only, or send ENROLLEE & CHECK).

You could certainly make an argument for this, but we're not proposing going
even that far. All we are proposing is removing the CONTEXT message entirely
from the BTP "protocol layer" (bad name, but basically we mean that part of
a "system" that is purely involved with talking to the coordinator(s) and
not involved with application specific interactions). This should be a
single change in the specification:

- add CONTEXT (or the information that is embedded within CONTEXT) as the
payload within the BEGUN message. If there is no CONTEXT then we have the
BEGUN as it currently stands. Thus, CONTEXT as a message only ever appears
within application messages.

> However, it appears to us that checking is a 95+% case in this
environment, and
> that the weight of a single excess element (which is not present when not
used,
> i.e. in the BEGIN/BEGUN and Cohesion CONTEXT propagation cases) is not a
great
> overhead or trouble.

I think you've got the wrong end of the stick. We are not pushing for
removal of any messages or their functionality.

> Our view, for what it's worth (2/20 votes), is that change in this area
would be
> possible, and even theoretically sweet, but is not strongly justified at
this
> stage in the life of the spec. We also suspect that
implementation/deployment
> experience would assist in further evaluating the type of change
envisaged.

This is based on implementation/deployment experience. Obviously the more
implementations that are out there the more experience gained, but we're not
coming at this from the "theoretical" stand-point.

> So, I would propose "defer" as the solution to the this issue.

I don't think this is a big issue and we can certainly live with it either
way. However, if we are to change it, we'd prefer to do it now and not have
to worry about any legacy implications.

>
> It would be useful to see a concrete textual alternative, with all of its
> ramifications worked out, if another resolution is proposed.

See above.

Mark.

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250