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: Re: Your proposal



Mark,
I think you are assuming a wider scope for what I am suggesting. What I am
suggesting is not trying to resolve problems of entire application logic or
workflow etc. It simply is a help for participants of the atoms to recover
independently, it is not a recovery of the workflow, business level
agreements and application.
The **fact** is that there will be some situations where some participants
of **atoms** are confirmed some canceled. When this happens the coordinator
already marked this atom 'not confirming' thus the business process or
workflow or simply the client knows the fact, it is not going to assume
opposite, it knows that A*azon is not going to send the book! so that it can
choose another atom, e.g another book store - but by letting know A*azon
that the transaction is failed we will be helping them not to send the book
because you are going to p*ssed off when you get a bill for the book that
you did not order - you already chosen another atom, another bookstore! Are
you suggesting that even if some participants of atom canceled coordinator
should confirm the atom?, if so how many of cancel will be enough to let
coordinator understand that the atom actually does exist anymore?
I am **assuming** that similar situation will occur enough that requires
some thinking to find a solution to **reduce** the inconsistencies that may
occur. This proposal, specially will **help** to the participant that is
confirmed while the **atom** failed. BTP does help the canceled participant
by sending CONTRADICTION message already - but does not require any actions
to eliminate the contradiction. It is also clear that this problem may be
attempt to be resolved by asking to the canceled participant to
re-think/revise its decision of canceling, because there are others already
confirmed which I think this is what Keith Weir was suggesting. I think this
second way of resolving the contradiction is valid but more cumbersome than
just letting the confirmed participants know the results of the atom and
take necessary actions whatever it might be (the atom is already canceled).
The best solution would be to require all the confirmed participants keep
the log until the 'complete' message arrived. This way it will be a complete
recovery for the atom and how the individual participant recover is not
concern of atom coordinator. But an optional qualifier in the CONFIRMED
message may do the job - I am assuming no participants wants to be doing
inconsistent work thus they all will set such qualifier (note that if such
qualifier exist coordinator should honor the request).
Shortly,
1) It is a fact that this situation will occur (I feel it will
happen more than you think),
2) It is clear to me that it is not an attempt to alter business
logic, it is a generic attempt to beware the consistency at atom level. We
have relaxed/reduced 'I' and 'D' of ACID but should keep 'C' as much as
possible - after all the protocol is to create some degree of consistency!
3) There are other alternatives that address the same issue (let the
contradicted participant revise its decision), but I think are more
cumbersome, and at the end it may still need to let confirmed participant
involve..
4) There are some performance penalty, I am not sure how much, needs
to be clarified, 5) The best solution would be as suggested
originally - all the participants keep the log around until a final_outcome
message received (not necessarily lock or not to do the job, they may
already have done the work),
6) The suggestion from Alastair and Peter (with minor modifications
for coordinator honoring every request for a final_outcome) will satisfy the
need since I am assuming all participants will be interested in requesting
the final outcome message!
Looks like I am repeating (like a broken record!) the same explanations...
hope I have been able to answer some of your questions and concerns.
Alastair, could you please re-send this for me to the list, I am still
unable to do so..

Regards,
--Sazi



At 10:39 AM 10/8/01 +0000, Mark Little wrote:
Despite the fact this this may now be moot, it's still an interesting point
of discussion. So, with that in mind ...

> Sazi > I will try not to go into other directions other than what is
> discussed technically, in the rest of email and discussions. It is clear
> that the proposal as shown above is very much aligned with what I was
> proposing.

Fine, but my point is that that proposal and yours are attempting to "solve"
a problem that cannot be solved by an individual participant or subset of
participants, unless we are suddenly introducing a lot more information
about the whole flow and composition of an application to individual
participants. If that's the case then we are into the domain of workflow,
and should let other committees take care of that.

> Now we are saying that if a single participant failure occurs (e.g., the
> insurance service) in the final commitment phase of this application
(after
> all participants said "OK" to PREPARE) some subset of the other
participants
> should be informed by the transaction service so they can do what?
>
> Sazi > With above proposal only those participants which requested to be
> informed will be informed. Since they requested it they know what to do.

No they don't! They may know what to "do" on an individual basis, but how
does this related to the entire application? As I said, I will get pretty
p*ssed if am*zon decided unilaterally to "unsend" my books just because the
insurance WS failed to confirm. If that's the approach *I* want to take then
I can do the compensation: am*zon don't have the global knowledge of what
constitutes the application. In addition, remember we have a separation of
web service from participant, so an individual participant may well only
ever do the equivalent of xa_commit/xa_rollback, and not see any of the
business logic that went into the work it is committing or rolling back. So,
how can a participant know what to undo/compensate?

> Sazi > Nobody is saying that in case of a failure of one participant, all
> the others will compensate, only those that requested may compensate. I
say
> may, we do not know what they will do, as you say we do not know the
details
> of this service. With this proposal we are now able to let the
participants
> know that the 'real' state of the transaction.

So now we go from having a subset of participants that failed to confirm
because of failures (typically I'd hope that would be the case) and the rest
that did confirm, to a grouping of participants that confirmed, those that
didn't because of failures, and those that compensated what they as
individuals did! Pretty hard to grasp what's going on now, I'd say.
Definitely not atomic!!

And what happens if those participants that want to compensate fail? Who is
coordinating that? Is there a compensation for the compensation? Do we then
need to tell the client?

In the end, if you actually *look* at what you want to do, and how it can be
accomplished in a failure resilient and reliable manner, you should
(hopefully) see that what is required is a compensation flow at the
application level, that is driven either by the client, or by whoever
composed the original application in the first place. This will then lead to
a workflow system. This is why transaction systems do not do workflow, but
workflow may well use transactions.

> Sazi > This proposal (although applicable for Cohesion) was for atomic BTP
> (Atoms) and per definition of atom, if one participants fails the atom is
> broken, there is no multiple successful outcome for an atom as there is
for
> Cohesion thus it is not (at least for Atom) a decision to be made by
> application level.

I understand this, but now there are multiple outcomes, simply because only
a subset of participants are informed, and there is no coordination of their
compensations at the BTP level.

> Sazi > See above comments.. It will not break any application domain
> knowledge.

Yes it will. See above.

> Sazi > Yes there is some performance penalty, not sure how much.. What
will
> we choose, consistency or performance at this particular situation..?

Both. Let the application or the application composer determine whether
compensation for the entire atom/cohesion is required, and program
accordingly. Do not impose performance degredation from below.

> There
> are places that one will definitely choose performance and places that one
> will choose consistency; For this particular case I would choose to beware
> the consistency of the Atom - as much as possible.

But as I said above, your proposal will blow consistency out of the water,
*unless* we introduce some kind of workflow scheme to coordinate the
compensations and ensure that all participants do the work.

> Sazi > I am not suggesting any particular action to be taken by the
> participants, they can do what ever they want to do, compensation or
> something else. Coordinator only informs the participants on what has
> happened to transaction - noting more.

But you have not answered my questions. Is this a reliable delivery? Does
the participant have to respond that it has done the work? If it doesn't the
coordinator does not know what state the participant is in, and hence what
state the atom is in.

> Sazi > There are many situation like you have described above in BTP.
These
> questions are addressed in BTP doc relevant sections on recovery (see
state
> diagrams). Mark, I think your concern is valid for Cohesion... for Atom we
> should do as proposed..

No. Cohesions are certainly an issue, but individual atoms are too. Let's
work up, and concentrate on the atoms. Please provide comprehensive answers
to *all* of the points I raised in this email and the previous one concering
recovery and reliability, and maybe then we can discuss whether this is a
viable option. I still believe it is not.

Mark.

----------------------------------------------
Dr. Mark Little
Transactions Architect, HP Arjuna Labs
Email: mark@arjuna.com | mark_little@hp.com
Phone: +44 191 2064538
Fax  : +44 191 2064203


Sazi Temel
Principal Consultant,
eCommerce Services,
bea Systems, inc. [www.bea.com]



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


Powered by eList eXpress LLC