[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Heuristics in BTP atoms
If we are talking about adding another message to BTP then this is an
imposition on the coordinator and the participant. I'd call that significant.
IMO this is more a management level issue: if I want my service/participant to
be informed of these kinds of issues then I can program accordingly, since the
contradiction will be know of (eventually) to the user of the coordinator.
I agree that this is all very subjective, and no one has any real figures
for Web Services. However, in our experience of using long-running transactions
and workflows, this kind of problem does not happen often. Whether we can
transpose this experience to Web Services is certainly an open issue that can
only be solved by time.
It won't help the failures, because unless I have written my participant to
expect this message, it will already have committed, and possibly gone away or
dispatched the books. Not every book shop, for example, will be able to afford
to employ a guy on a motorbike who can shoot off and catch the
book-dispatch-truck and call it back when they're told that the insurance
failed.
As a slight aside, you could always order the invocations on participants
to reduce the chances of this happening.
True, but I am also stating that in general this would not solve the
problem anyway, no matter how often it occurs.
So is this a message that has to be sent? If so, the coordinator now needs
to keep persistent the information about all of the participants after the end
of the second phase.
Why should all confirmed participants receive this message? Are we assuming
they will all want to know? This is not the same as sending PREPARE and CONFIRM
to them, since we know they all *need* to see these messages. This new message
is more informational, since it cannot be guaranteed to have an affect on the
outcome of the BTP, unless we say to programmers that they should not confirm on
CONFIRM. So, if it's informational, I don't want my coordinator to *have* to
send it, so it doesn't need to make this information persistent. I also don't
want to have to send it to all participants, and I think programmers of
participants may well object to having to deal with it. In which case, it's more
optional than anything, and should be dealt with at a higher level than BTP.
Management interfaces.
It's different for the cancelled participant to have to wait: it caused the
problem in the first place. To impose this burden on confirmed participants (and
*all* confirmed participants at that) means that the coordinator changes, the
participants change, and the service has to change. This is much more a workflow
issue IMO. We should be looking at trying to persuade IBM, MSFT, and even HP to
layer their workflow languages on to BTP.
OK, but why can this not be dealt with at the application level? A
compensation operation may not be appropriate at all, or may well involve having
to talk to all of the participants in a coordinated (no pun intended) operation.
One participant does not have sufficient information to do a compensation on
behalf of the *entire* cohesion.
Compensation is definitely a collaboration between the user and the
participants. I'm not saying that what you propose is invalid, only that it
should not be dealt with at the BTP level.
Fine, but what you are saying is that BTP should take care of this,
and that a single participant knows how to compensate for itself. Compensation
for a single participant may well not be sufficient to drive compensation for
the entire cohesion. This is why workflow systems work the way they do. Let's
not make BTP do everything, but let's try to leverage other Web Service
"standards".
Obviously I disagree because of the impact on the coordinator, participants
and services, for something which IMO isn't even a 20% case.
How you implement what do to on reception of a CONTRADICTION message is up
to the participant. However, I would advise that you do roughly the same as a
transactional resource does for a heuristic: when a participant makes a decision
that could be counter to the actual outcome it should record this decision. When
the coordinator has determined that the outcome is different, it sends a
CONTRADICTION message to the participant (similar to sending an OTS forget, for
example). A "heuristic" outcome means that a participant has done something that
means the resultant "transaction" isn't atomic, and possibly cannot be undone
automatically: participants don't know the semantics of the work that they have
just "committed" or "undone" - it's like saying that an OTS Resource that wraps
X/Open knows about the SQL statements that were first at the connection. As a
result, I'd hope that a participant that generates a heuristic then reports this
fact to some administrator. Then it's down to that individual to sort out,
possibly looking back through logs.
But the participants that did the right thing by the coordinator, don't
need to do anything. If the entire activity needs compensation then that's a
higher-level issue. (Sorry to sound like a broken record!)
My point is that we should not be telling people to ignore heuristics. If
that is the case then why have the message in the first place.
OK, if you are not saying that CONFIRM is a pre-confirm then there need not
be any resource blocking. However, there is now the need to maintain logs at the
participant, and for the coordinator to run 3 phases.
Agreed, which is why to some extent workflow can help.
Which is why a workflow could then be used to fire-off another compensation
cohesion. BTP should be useable in a recursive manner like this.
It would be if you were saying that CONFIRM does not mean "do the work in a
non-undo-able manner".
It's a performance penalty on all participants because obviously a
CONFIRM-ed participant doesn't know if a CONTRADICTION will ever happen. So,
even if a CONTRADICTION does not happen, it must receive this third phase
message (and hence the coordinator must send it). Unless we say that "if you
don't receive a message by time X, you can assume a CONTRADICTION didn't
happen", but then that's very shaky ground!
Yes, but if there is a qualifier than it's a deployment/useage situation
and it's up to the participant and user to determine if that is the right thing
to do. If I as a user don't want that, then I should look for participants that
advertise such.
It is application specific.
I didn't say it made BTP less useful. More bloated, perhaps. There are
applications that could well use what you suggest. However, it runs the risk of
discouraging others from using BTP. I think the trade-off is not worth the risk
at this stage. If we find that there is a significant use-case for this
extension *after* BTP is in use, then we can re-examine the protocol. However, I
suspect there will not be, because WSFL or XLANG, or whatever may be layered on
BTP to accomplish the same result with no impact on participants who don't want
this.
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC