OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [business-transaction] Sazi's discussion


Hi Sazi, all,

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

I agree that the parts of an atom have a different relationship to each
other than parts of a cohesion.

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

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
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) and worse
still there is no record that this is the case at the subordinate.  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 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*. Trying to rush
through a specification with blinkers on without discussing and resolving
issues arising is to my mind a recipe for disaster. What is the old adage:
"decide in haste, repent at leiusure!"

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.

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/










[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC