RE: Re: [business-transaction] Sazi's discussion

[Keith Weir <keef@consultant.com>]

Hi Mark,

I had hoped to generate a little light as opposed to heat:-) My apologies if my tone was inflammatory. I meant only to indicate that Sazi has brought up a valid *problem* that did not appear to be being given the consideration it deserved. Further comments below. 

"Mark Little" <mcl@arjuna.com> wrote:

>> 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 have been following the thread. I don't think there really is a risk of the whole specification unravelling.

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

If the atom stuff doesn't really work in the failure cases perhaps it should be removed... After all 'Occams Razor' - just enough to do the job.

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

But the behaviour is very different, as I describe below.

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

Ah, but then no system worth it's salt does commit serially, so your argument does not apply (Commit has already been issued to other participants). Even if it does, the subordinate is still obliged to keep a heuristic log as I describe. From the subordinate's point of view, it is contrary to the outcome of the transaction because it was told to commit, and did not do so. The superior will in either case have to keep a heuristic log for the transaction. 
>
>> 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.

I guess we are hampered here by not having a current version of the specification to refer to. As I described, Heuristics are different from one of the parts of an atom cancelling. Introducing a rule whereby a participant cannot cancel after prepare is one solution to the overall problem. 

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

BTW, I did not say that the onus was to fall on the N-1 participants. I think you are now arguing with Sazi's specific proposal. I was saying that he has brought up and interesting point, that I consider to be a valid problem. Personally I am not sure I wholly agree with the specific solution he put forward, but I do commend him for trying to produce a solution. I'm sure there are probably other ways to resolve this problem - I would be interested to hear your proposals.

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

Well, I do not believe we will end up "throwing the baby out with the bathwater" in looking at and resolving this issue. I also do not believe addressing this is chasing our tails.

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

Personally, I do not believe it would be wise to adopt the specification without coming to some resolution on this issue, and in any case I believe that as others have suggested the specification should undergo a review before adoption - this does not seem unreasonable.

Regards. Keith S. Weir
-- 

_______________________________________________

Sign-up for your own FREE Personalized E-mail at Mail.com

http://www.mail.com/?sr=signup



Have you downloaded the latest calling software from Net2Phone? Click here to get it now!

http://www.net2phone.com/cgi-bin/adforward.cgi?p_key=NH211JK&url=http://commcenter.net2phone.com/