Re: [business-transaction] Sazi's discussion

[Mark Little <mcl@arjuna.com>]

> you have brought up an interesting point. One that should not simply be
> brushed aside in order to get a specification out.

Just to make something clear: we are not brushing aside any "interesting
points" to rush out a specification. What we are doing is attempting to stop
the entire BTP specification from unravelling and ending us up back where we
started 6+ months ago. I'm not sure you have been following all of this
thread, since I think you are no longer a member of OASIS or this TC, but
several weeks ago I said that we will never be able to produce a
specification that is perfect for everyone.

I can't think of a single spec. produced by any organisation that involved
multiple independent companies, that could be held up as having been agreed
with completely by all those parties. In addition, no specification in our
field should ever be considered frozen. There should definitely be some kind
of revision task force to update the specification as bugs are found,
requirements change, etc.

What we are trying to do is ratify a series of decisions that were made in
quorate sessions months ago. Even if we were to consider Sazi's proposal, it
would be an *update* to the specification as it is adopted. We need to draw
a line in the sand and say no more prevarication and attempts to undo
previous votes. Let's agree the core specification as it is now, and move on
to improve it with additions, not subtractions.

> In an atom we started with the premise that the parts had an intimate
> relationship to each other and gauranteed that an atom would either
> confirm or be cancelled as a whole. [This was part of the original scope,
so nothing has changed here.]

With the exception that sometimes it simply isn't possible to be atomic, in
*exactly* the same was as it isn't with TP monitors today. Failures happen
after prepare.

> A part of an atom cancelling whilst undergoing the confirmation phase is
> very different from the case of heuristics in a traditional 2PC
> transaction.  [Subordinate sends CANCEL after having sent PREPARED.]
>
> In the case of heuristics in 2PC, the heuristic participant is obliged
> to record the fact that it is contrary to the outcome of the transaction

Not quite true, since at this point it doesn't know what the final outcome
of the transaction will be. If it's the first participant to throw a
HeuristicRollback, for example, then a TP system may well simply send
rollback to all other participants and no heuristic happened as far as the
user is concerned.

> and maintains this in a log such that an adminstrator can rectify the
> matter in some way.  With participant cancelling in the way it is at the
> moment, the parts of an an atom can be inconsistent with the outcome of
> the atom (contrary  to the basic premise we started with)

I believe your understanding of the basic premise is not correct. At the
last face-to-face we had, there was discussion on this, and heuristics are
possible within an atom, and that it should not return CANCELLED from
CONFIRM, but MIXED (or HAZARD as I think it was agreed to rename it). I have
some minimal notes on this, but hopefully someone else has better
recollection.

> and worse
> still there is no record that this is the case at the subordinate.

See above.

> When
> an external administrator attempts to reverse a part of an atom to get
> the entire atom to a cancelled state in order that another may replace
> it, there is no evidence available to the subordinate to show what is
> doing other than reneging on an agreement.  An interesting point is that
> the evidence is needed at participants which have not themselves
> cancelled.

I don't think that the overhead for fixing the problem should fall on N-1
participants to compensate if 1 caused the problem in the first place.

> I do not pre-suppose a particular resolution to this problem, however I
> do believe strongly that this is a fundamental issue with the protocol
> which *should be discussed* and *should be resolved*.

It was at the last face-to-face, although since we have no specification to
look at I can't say if it made it in.

> Trying to rush
> through a specification with blinkers on without discussing and resolving
> issues arising is to my mind a recipe for disaster.

These aren't blinkered decisions we are taking. No one is saying that if we
accept the resolution we have a final specification, only that we have a
subset of the final spec.

> What is the old adage:
> "decide in haste, repent at leiusure!"

And let's not chase our tails so much that by the time we agree that all the
i's are dotted and t's are crossed, the applicability of BTP has been lost.
It will never be perfect, let's just face that fact and move on. We need a
base-line from which to work to fix its imperfections, and we believe that
we have that now.

>
> So Sazi, I believe you have raised an interesting an very valid point
(that does not change the scope of the specification)!
> We should not drop this point in order for a quiet life - we will all
regret it
> later if we do so. We should discuss it now and try and resolve it.

Fine, let's discuss it based on the adopted specification as agreed by the
last face-to-face. And if you feel so strongly about this, it would be a
good idea for you to become a member of OASIS if you haven't already done
so.

Mark.

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