First, please post to the User Forum in future. That's the right place for such questions.

Secondly, it has nothing to do with requiring an accurate failure detector: with the exception of a quantum-based detector, there's no such thing and all systems use failure suspectors (a subtle, but important difference). What I'm getting at here is that irrespective of whether we're talking closely coupled or loosely coupled systems, accurate failure detection is practically impossible as is accurate failure suspicion. Truly asynchronous systems introduce even more problems around completeness and correctness.

If a participant believes that the coordinator has failed, then it can call back to the coordinator to determine the outcome. Repeated failures to contact the coordinator MAY be interpreted by some participants as the coordinator having failed and the action subsequently taken by the participant will be implementation dependant. In an implementation based on the traditional ACID model, heuristics may then occur (assuming the participant got past the prepare phase; if it didn't then we're OK since the participant can rollback and be sure that will be the eventual outcome of the transaction). In an extended transaction model, you can get the same behaviour but the result MAY be less of a problem.

If the coordinator suspects a participant failure then it again depends where the failure is suspected: if it is before prepare, then we're using presumed abort and the coordinator can rollback and be sure that all participants will eventually rollback (even if it can't contact them at the moment: those that have failed will not have to do anything upon recovery). If the failure is suspected after the participant has prepared, then the failure recovery subsystem will keep trying to issue the commit (assuming the coordinator had subsequently decided to commit). If after some implementation specific retry period (which could in theory be until the end of the universe) it still hasn't been able to reach the failed participant, then it may flag this to a sys admin to figure out.

So in the end we don't need accurate failure suspicion. If we're wrong (either end of the protocol) we may cancel/rollback more transactions than we really need to, but ultimately everything will be OK.

"XiaoQJ" wrote:
Thank you for helpful reply.
To summerize your comment:

Most transaction processing is a centric-based solution of the consensus problem. Usually a two phase completion is adopted
(1) Vote Collection (bottom-up message flow) to make final decision non-trivial
(2) Decision Diffusion(top-down message flow) to realize consistent agreement

Thus the existence of centric arbitrator reduces the complex consensus problem to relative easy "at lease one" message transmission.
(1) To tolerate duplication of messages(due to inaccurate failure suspector), idempotent operations are needed, saying Prepare, Abort, Commit, e.g.
(2) To tolerate crash of coordinator, resort to recovery.

My point is, it seems in ACID transaction, coordinator notifies user the final outcome just out of courtesy. So it's possible for user to think of the transaction as rolledback but in fact it's committed.

The relationship between a parent scope and the child scope is relative the same. The parent scope needs a correct sense over the outcome of its children, which might be the basis to adjust its control flow. Maybe the sub-scope could to use again the "at-lease-once" message transmission to notify parent scope its outcome, which is witnessed from user as if it's an accurate failure detector.

"XiaoQJ" wrote:
I mistake the peer autonmy from parent-child autonomy, If we borrow the concept of "Autonomy" from workflow. The same concepts are implemented in JBossTS. Coordinator/Participant corresponds to the parent-child autonmy. Completion/CompletionWithAck Protocol corresponds to peer autonomy

, which ensures that the user would get the outcome notification in a committed transaction. But seems such a reliable outcome notification mechanism is mentioned only in WS-AT.

Is it also implemented in WS-BA?

Is a special log component needed for transaction terminator to acquire the notification reliably?

Will such a completion protocol disable the one phase commit optimization?

"XiaoQJ" wrote:
Back to the fault detection question, When viewing WS-BA state transition graph, confused by the Fault/Faulted message pair. It's impratical to compel all participants to conform a Fail&Notify style failure model. So fault-suspecter you mentioned may be a necessity in WS-BA. Why it's left out in the WS-BA specification?

"XiaoQJ" wrote:
Propabaly, the concept of failure suspecter is implicit mentioned in the state transition table. Because there're two timers triggering "Comms Times out" and "Transaction Expiration" events.

"Comms Times out" is an effective detector for message loss in synchronous environment.

Although the transaction time-out mechanism may not take effect in 2nd phase, it can also shield crash failure in 1st phase.

Btw. interposition can really be helpful to make such a dectection accurate.

So I agree that interposition is useful for performance and security reasons. However, the use of interposition in Web Services doesn't imply synchronous behaviour at all. That's a deployment/use-time choice.

"XiaoQJ" wrote:
Then with current network conditions, how WS-BA address the problem of fault suspector. When viewing the released WS-BA spec, we can easily image some special execution runs, that causes inconsistency between coordinator's assumption of participant's state and the real state.

I read a paper by Fischer, Lynch and Paterson that proves in a real asynchronous env., such a consensus cannot be achieved.