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


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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

Subject: Re: [wsbpel] BPEL specification misconstruction

Hi Genov,

If I read your code and description correctly:

(A)  I am not sure there will be a situation where "Before handling the fault, it terminates its root activity and then it handles the fault that has been thrown thus ‘suppressing’ somehow the fault that has been thrown by the throw activity." (as you put in your scenario #1)  ... Because there is a <catchAll> in "SecondFlowScope" which prevent the "tns:myFault" from bubbling upwards.
(B) Let's assume there is no <catchAll> in "SecondFlowScope" for a moment. Then, there is a typical / classical fault racing condition situation. Whenever there are parallel activities, there is always a possibility of multiple faults triggered simultanously. And, the spec does require that only one fault to be caught (i.e. uninstall all other fault handlers, once one fault handler got activated) (In section 13.4 "Fault Handlers", search for "uninstall" you wil find the related text). Hence that implies the other fault will got ignored. (That's my impretation of the spec).
(C) Actually, there is a racing condition between execution "tns:myFault" fault and the join-condition testing in "FirstFlowScope" too. If execution "tns:myFault" is way faster than the join-condition testing, the "bpws:joinFailure" may not triggered at all. (That is kind of your Scenario #2). In short, scenario #1 and #2 are just different versions of the same racing. Both of them are possible.  This racing condition results are depending on BPEL implementation and runtime env.
(D) For your scenario #3, your intepretation is sync with mine. Pretending there is no <catchAll> at "FlowScope" for a moment. Then, the fault will bubble up all the way to the <process> level. And, the whole process will end with fault handler activated to handle "tns:myFault".

In short, those are same old classical racing condition of parallel faults. A BPEL implementation needs to deal with it, as required by the spec. And, the non-determinism is a natural implication of parallelism.


Alex Yiu

Genov. Genadi wrote:

Hi All,


After writing a simple test for the flow activity and testing the bpws:joinFailure fault, I encountered certain ambiguities in the way my test process would behave. The test process that I am about to discuss is attached to the current mail. So let’s get down to the point:


I’ll explain the scenario from starting point the flow activity onward. It has two scopes and a single link used for synchronization dependency targeted at the first scope name="FirstFlowScope". The execution of the second scope is not obstructed by any link or serialization issues so it proceeds (name="SecondFlowScope"). After executing the assign (first activity from the inner sequence for the corresponding parent scope), a throw activity throws a fault. The parent sequence is notified accordingly for the fault occurrence of its child and takes the proper measures for such a case.

We reach the third element from the latter sequence (a sequence which contains the source of the link defined in the parent flow). Because of the abnormal situation, the state of the third element (sequence) is changed to dead path (it has never been invoked) and all its source links are evaluated with status ‘false’. So here we come to the unresolved behavior for the process (or me personally).


1.)    Scenario: The sequence that contains the source for the link name="firstLink" notifies immediately the target activity of that link, that its status has changed. This would mean the next activity that is going to be executed is the first child scope for the flow element scope name="FirstFlowScope". However it throws a bpws:joinFailure which is caught from the scope parent of the present flow – scope name="FlowScope". Before handling the fault, it terminates its root activity and then it handles the fault that has been thrown thus ‘suppressing’ somehow the fault that has been thrown by the throw activity.

2.)    Scenario: The sequence doesn’t notify the target activity right away but waits until the thrown fault is (un)handled. In this case the fault is handled by the scope name="SecondFlowScope". So the fault that occurred from the throw activity is properly handled and consequently the target activity of the link name="firstLink" is notified. Subsequent execution is as mentioned above in 1st Scenario.

3.)    Scenario: Much like 1st Scenario but the fault thrown from the throw activity is not suppressed and after executing the fault handler for scope name="FlowScope" (all children including flow, children scopes and their relevant fault handlers have been disabled. So there is no proper fault handler to handle the occurred fault and the process terminates abnormally.


What should be the proper behavior of the process modeled for this simple test case of mine?

Thanks in advance!


Best Regards,

Genadi Genov

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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