[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: Re: wsbpel editors 4/27/2006: (Section 12.4.4) Fault Handlingand Termination]
As discussed in today's meeting.
--- Begin Message ---
- From: Monica J Martin <Monica.Martin@Sun.COM>
- To: Dieter Koenig1 <dieterkoenig@de.ibm.com>
- Date: Fri, 28 Apr 2006 12:51:59 -0700
>koenig: Hi Monica, I may not completely get the point of the proposed change. > mm1: Dieter, thanks for the swift response and consideration. My point was to provide some explicit language so people have a better idea about what happens with explicit, default or internal fault behavior when completion condition and termination may be involved. That is why I provided the use cases. >When a termination signal from the outside arrives at a scope while it runs >its fault handler, I do not think that any fault propagation (e.g. due to a >rethrow) should occur. > mm1: Perhaps you and Alex should discuss this further. If you look at the text in Section 12.4.3 below: Forced termination for a scope applies only if the scope is in normal processing mode. If the scope has already invoked a faultHandler, then the terminationHandler is uninstalled, and the forced termination has no effect. The already active faultHandler is allowed to complete. Are you indicating the fault doesn't get propagated then? This appears converse to the text although I understand this was a point of discussion (confusion?) with the editors' team (seeing the comments I read). See Case 2 and, under some conditions, Case 3. > (a) If the termination was caused by an external fault then additional >faults will be lost anyway. > (b) If the termination was caused by a completion condition then >additional faults can be ignored. >It may help to add a word of clarification for (b). > > mm1: I'll not address (a) and (b) for now. Please look at the use cases, and the conditions that apply. I've provided the use cases previously to Alex so we could discuss this in detail. Thanks. >Kind Regards >DK > > Dieter König Mail: dieterkoenig@de.ibm.com IBM Deutschland Entwicklung GmbH > > Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Schönaicher Strasse 220 > > Architect, Business Process Choreographer Fax (office): (+49) 7031-16-4890 71032 Böblingen > > Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Germany > > > > > > > > Monica J Martin > <Monica.Martin@Su > n.COM> To > Dieter Koenig1/Germany/IBM@IBMDE, > 27.04.2006 19:37 Alex Yiu <alex.yiu@oracle.com>, > Danny van der Rijn > <dannyv@tibco.com>, "'Marin, Mike'" > <MMarin@filenet.com> > cc > Ron Ten-Hove > <Ronald.Ten-Hove@Sun.COM> > Subject > wsbpel editors 4/27/2006: (Section > 12.4.4) Fault Handling and > Termination > > > > > > > > > > >Editors, >We've had a detailed discussion about this text in Section 12.4.4. I've >provided a few suggestions for changes here, and provided use cases to >show how understanding this is important. I see from the editors' >discussion that there was some confusion around fault handling and >termination as well, so perhaps this point is relevant for clarity for >WS-BPEL v2.0 users. Note: I believe the text is consistent with the >current editors' v1.3 for Chapter 12. Changes are only proposed for >first and second paragraphs (with only a reference in paragraph 2). I'd >ask for some responses before sending the TC list. Thanks. > > Change from: Forced termination for a scope applies only if the > scope is in normal processing mode. If the scope has already invoked > a faultHandler, then the terminationHandler is uninstalled, and the > forced termination has no effect. The already active faultHandler is > allowed to complete. > > The terminationHandler for a scope is permitted to use the same > range of activities as a faultHandler, including the > <compensateScope> or <compensate> activity. However, a > terminationHandler cannot throw any fault. Even if an uncaught fault > occurs during its behavior, it is not rethrown to the next enclosing > scope. This is because: (a) the enclosing scope has already either > faulted or is in the process of being terminated, which is what is > causing the forced termination of the nested scope; (b) the scope > being terminated is a branch of a parallel <forEach> and early > completion mechanism triggers the termination as > <completionCondition> of <forEach> is fulfilled. > > Forced termination of nested scopes occurs in innermost-first order > as a result of the rule (stated above) that the terminationHandler > is run after terminating all activities (including scope activities) > directly enclosed within its associated scope that are currently >active. > > Change to: > Forced termination for a scope applies only if the scope is in > normal processing mode. If the scope has already invoked an explicit > or default faultHandler (and rethrow applies), then the > terminationHandler is uninstalled, and the forced termination has no > effect. The already active faultHandler is allowed to complete and > propagation occurs. Regardless of whether a fault is handled > internally (no rethrow) or via an explicit or default faultHandler, > the scope is considered finished or completed unsuccessfully. > > The terminationHandler for a scope is permitted to use the same > range of activities as a faultHandler, including the > <compensateScope> or <compensate>. However, a terminationHandler > cannot throw any fault. Even if an uncaught fault occurs during its > behavior, it is not rethrown to the next enclosing scope. This is > because: (a) the enclosing scope has already either faulted or is in > the process of being terminated, which is what is causing the forced > termination of the nested scope; (b) the scope being terminated is a > branch of a parallel <forEach> and early completion mechanism > triggers the termination as <completionCondition> of <forEach> is > fulfilled (as evidenced in the cases above). > > Forced termination of nested scopes occurs in innermost-first order > as a result of the rule (stated above) that the terminationHandler > is run after terminating all activities (including scope activities) > directly enclosed within its associated scope that are currently >active. > >Reason: We have three use cases that evidence a need to specify this >more explicitly and clearly. > ><scope 1> >... >` <forEach parallel="yes" ...> > <startCounterValue ...>1</startCounterValue> > <finalCounterValue ...>5</finalCounterValue> > <completeCondition> > <branches >countCompleteBranchesOnly="no">3</branches> > </completeCondition> > <scope 2> > ... > </scope 2> > </forEach> ><scope 1> > >Notes: >a. forEach has parallel="yes". >b. Branch is the implicit flow created by forEach. > >Case 1: >Scope 2 (branch 1, branch 2, branch3) all execute successfully, so, the >other 2 incomplete branches (branch 4, branch5) are terminated, >termination semantics applies here. > >Case 1 is fairly understandable, termination semantics kick in as three >branches have completed (successful or unsuccessful don't matter as >'successfulBranchesOnly' is 'no'). > >Case 2: >Scope 2 (branch 1) and Scope 2 (branch 2) execute successfully, but >scope2 (branch 3) has a fault and no fault handler is installed in >scope2. > >This involves a default faultHandler that would terminate all activities >within the scope (according to Section 12.4.1). Here is where we see that >the specification needs more clarity. The default faultHandler >propagates to the enclosing scope (assume Scope 1). As with the >termination handling, Scope 2 would be terminated using the (implicit) >terminationHandler of those scope instances (not the ><completionCondition> which no longer applies). > >Case 3: >Scope 2 (branch 1) and Scope 2 (branch 2) execute successfully, but >scope2 (branch 3) has a fault and a fault handler is installed in scope2 >that handles the fault internally and does not rethrow any fault. In >this case, scope 2 (branch 3) is completed but unsuccessfully. > >In Case 3, the fault handler occurs before the evaluation of the branch >(that is part of early completion). The text from Section 12.4.4 >implies that: Even if early termination applies, you have a faultHandler >invoked, the forced termination doesn't apply. The faultHandler is >allowed to complete and the terminationHandler is uninstalled. We're not >addressing here any potential race condition between termination signal >coming from outside of a scope instance and explicit faultHandler (inside). > >If the explicit faultHandler rethrows, see results for Case 2. If the >fault is handled internally (no rethrow), the scope is consideded >finished/completed unsuccessfully. At that time, the ><completionCondition> will be evaluated. As you are branch 3, and three >have completed, the termination semantics would apply. > >Note: Case 2, Case 3 may relate to our previous TC discussions on 'break >and continue'. > > > > > > >--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]