[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 135 - Proposal to vote
Satish Thatte wrote: >If we stick with the current semantics of termination handlers, they >exist only to clean up, not to propagate faults outwards. In other >words, the associated scope is known to have been forced to fail and "no >one cares about it any more, including its internal failures". Thus all >the completion handler needs to wait for is that all termination >handlers are done with their work. Faults in them will be swallowed as >usual. > > I'm fine with this behavior. I do believe the outcome of termination could affect completion, as it could also affect fault handling, but since there's strict ordering, one can determine the outcome in other ways. We will just have to remember to change the text accordingly. Assaf >-----Original Message----- >From: Assaf Arkin [mailto:arkin@intalio.com] >Sent: Wednesday, September 29, 2004 7:39 PM >To: Satish Thatte >Cc: Alex Yiu; Danny van der Rijn; wsbpel@lists.oasis-open.org >Subject: Re: [wsbpel] Issue 135 - Proposal to vote > >Satish Thatte wrote: > > > >>We should keep forced termination semantics for all activities >> >> >including > > >>scope activities as it is today when thinking about premature >>completion. I believe the consensus is that when a scope is >> >> >prematurely > > >>completed, all currently running activities nested in that scope will >> >> >be > > >>forced to terminate. Let me know if you disagree with this. >> >> >> >> >I'm definitely in support of this consensus. However, if we were to add >a completion handler, then a nested scope could be terminated while the >enclosing scope is neither faulted nor being terminated. > >Should the completion handler be satisfied that all termination handlers > >have executed and similarly ignore any faults, or should the completion >handler make the assumption that all termination handlers have >successfully recovered, and if one (or more) failed, then a fault >handler would be invoked instead of the completion handler? > >Assaf > > > >>Satish >> >>-----Original Message----- >>From: Assaf Arkin [mailto:arkin@intalio.com] >>Sent: Tuesday, September 28, 2004 12:37 AM >>To: Alex Yiu >>Cc: Satish Thatte; Danny van der Rijn; wsbpel@lists.oasis-open.org >>Subject: Re: [wsbpel] Issue 135 - Proposal to vote >> >>The suggest text changes include; >> >> The termination handler for a scope is permitted to use >>the same range >> >> >> of activities as a fault handler, including the <compensate/> >>activity. >> However, a termination handler 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 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. >> >> >>Will this behavior change if we add completion handlers? >> >>Let's say that scope S contains nested scope N. Early completion of >>scope S forces scope N to terminate. The termination handler of scope N >> >> > > > >>attempts to perform some clean-up, however, fails to complete >>successfully. At which point, the proposed text suggest that the fault >>be ignored and the completion handler of scope S be allowed to proceed. >> >> >> >> >> >>>(2) >>>One more catch / clarification is: do we want to add >>>"terminationHandler" to the process level also, besides scope level? I >>> >>> >>> >>> >> >> >> >> >>>tend to say yes. >>> >>> >>> >>> >>I concur. In my opinion we should have scope capabilities at the >> >> >process > > >>level. >> >>Assaf >> >> >> >> >> >>>(3) >>>About the racing faults questions, let me re-iterate a bit. Those >>>questions are not directly related to forced termination situation. I >>>should start a brand new thread for that question. :-) >>>(3)[i] >>>When two faults happen at the same time. One fault will win, what will >>> >>> >>> >>> >> >> >> >> >>>happen to the other fault? Got swallowed? or Got thrown to the parent >>>scope? E.g. >>><scope name="A"> >>> <flow> >>> <sequence name="S1"> ... <throw faultName="foo:bar" /> >>></sequence> >>> <sequence name="S2"> ... <throw faultName="foo:bar2" /> >>></sequence> >>> </flow> >>></scope> >>>(3)[ii] >>>Once a fault is caught and before the actual logic of the matched >>>faultHandler is executed, other fault handlers of the scope will be >>>un-installed and any currently running activities (including nested >>>scopes) within the scope will be forcibly terminated. Which one happen >>> >>> >>> >>> >> >> >> >> >>>first? uninstallation or forceably termination? Or the spec should >>>leave it unspecified? >>> >>> >>>Thanks! >>> >>> >>>Regards, >>>Alex Yiu >>> >>> >>>Satish Thatte wrote: >>> >>> >>> >>> >>> >>>>Alex, I just realized that the double termination case I outlined in >>>> >>>> >>>> >>>> >>fact doesn't occur because completion handlers should not run until the >>prematurely completed scope has be shut down through termination of all >>activities. >> >> >> >> >>>>On the issue of racing faults, only one fault will win and its fault >>>> >>>> >>>> >>>> >>handler will run (whether custom or default). The other faults will >>find their handlers uninstalled. The same applies to forced >>termination. If there is a race between forced termination and an >>internal fault, one of the two will win. >> >> >> >> >>>>Does that make sense? >>>> >>>>________________________________ >>>> >>>>From: Alex Yiu [mailto:alex.yiu@oracle.com] >>>>Sent: Mon 9/27/2004 4:59 PM >>>>To: Satish Thatte >>>>Cc: Danny van der Rijn; wsbpel@lists.oasis-open.org; Alex Yiu >>>>Subject: Re: [wsbpel] Issue 135 - Proposal to vote >>>> >>>> >>>> >>>>Satish, >>>> >>>>You raised a very good point about the premature completion. :-) >>>> >>>>Anyway, I was trying to suggest to add something similar to the >>>> >>>> >>>> >>>> >>following for clarity: [I hope it makes sense :-) ] >> >> >> >> >>>> The second or subsequent attempt to forcibly terminate a scope >>>> >>>> >>>> >>>> >>will be ignored. The terminationHandler (if still running) invoked by >>the first attempt will be allowed to continue. The terminationHandler >>will NOT be invoked more than once. >> >> >> >> >>>> >>>> >>>> >>>>Few more questions about interaction between faultHandler and >>>> >>>> >>>> >>>> >>termination to make sure my understanding is correct: [ Most questions, >>if not all, are applicable to the existing spec already without the >>proposal. ] >> >> >> >> >>>>* Once a fault is caught and before the actual logic of the >>>> >>>> >>>> >>>> >>matched faultHandler is executed, other fault handlers of the scope >> >> >will > > >>be un-installed and any currently running activities (including nested >>scopes) within the scope will be forcibly terminated. Which one happen >>first? uninstallation or forceably termination? Or the spec should >> >> >leave > > >>it unspecified? This question leads to the racing codiition of parallel >>faults in the next bullet. >> >> >> >> >>>> >>>>* In a scope of parallel flow activity, there may be multiple >>>> >>>> >>>> >>>> >>faults happen at the same time frame. One fault will get caught. The >>other fault get swallowed silently? Or, the other fault will be thrown >>to the parent scope? >> >> >> >> >>>> >>>>* As of the current shape of the spec + this issue proposal (i.e. >>>> >>>> >>>> >>>> >>when without pre-mature completion), the only way (as of now) to >>terminate an activity by internal condition is through a fault handler. >>And, my analysis on faultHandler behavior goes as following: >> >> >> >> >>>> * If there is another forced termination from the parent >>>> >>>> >>>> >>>> >>scope, the forced termination will be ignored by the scope in the >> >> >middle > > >>of fault handling. >> >> >> >> >>>> >>>> * If there is a fault within a faultHandler, it will be >>>> >>>> >>>> >>>> >>propagated to the parent scope. And, this scope is marked faulted and >>the BPEL engine will not try to attempt the faulted scope again. >> >> >> >> >>>> * If there is another fault raised by a child activity or >>>> >>>> >>>> >>>> >>scope after the original fault is caught and before the termination >>happens, then the other fault will be either ignored or rethrown >>depending on the answers to the above questions. In either case, it >> >> >will > > >>not trigger another forced termination of the same set of scope and >>activities. >> >> >> >> >>>> >>>> >>>> So, is it fair to say there is no such a case that a BPEL engine >>>> >>>> >>>> >>>> >>will try to terminate a scope more than once due to internal >> >> >conditions, > > >>if premature-completion is not involved in the picture? >> >> >> >> >>>> >>>> >>>> >>>>Thanks! >>>> >>>> >>>>Regards, >>>>Alex Yiu >>>> >>>> >>>>Satish Thatte wrote: >>>> >>>> >>>> It is not necessarily true that a scope will be forced to >>>> >>>> >>>> >>>> >>terminate only once. If we do premature completion with a completion >>handler then a fault in the completion handler may cause an attempt to >>forcibly terminate a scope more than once. >> >> >> >> >>>> >>>> >>>> >>>>________________________________ >>>> >>>> >>>> From: Alex Yiu [mailto:alex.yiu@oracle.com] >>>> Sent: Monday, September 27, 2004 2:33 PM >>>> To: Satish Thatte >>>> Cc: Danny van der Rijn; wsbpel@lists.oasis-open.org; Alex Yiu >>>> Subject: Re: [wsbpel] Issue 135 - Proposal to vote >>>> >>>> >>>> >>>> >>>> Hi, >>>> >>>> +1 to Satish's proposal. >>>> >>>> Just want to suggest a couple of minor things to add explicitly >>>> >>>> >>>> >>>> >>to the spec for clarity >> >> >> >> >>>> * A forced termination is an abnormal termination of a >>>> >>>> >>>> >>>> >>scope. The compensation handler of a scope will not be installed after >> >> >a > > >>forced termination. (To distinguish the terminationHandler from the >>potental completionHandler) >> >> >> >> >>>> * From the text from other parts of the existing spec, I >>>> >>>> >>>> >>>> >>can infer that there is NO such a situation that a BPEL engine will try >>to terminate a scope more than once due to internal conditions. Could >>someone confirm my inference? >> >> >> >> >>>> >>>> On the other hand, it may be possible that people may >>>> >>>> >>>> >>>> >>try to "terminate" a process gracefully from a BPEL managment tool more >>than once, instead of "kill" it immediately? >> >> >> >> >>>> >>>> Do we want to make this explicitly by saying the second >>>> >>>> >>>> >>>> >>or subsequent attempt to terminate an activity / a scope which is being >>terminated will be ignored? Hence, the terminationHandler of a >>particular scope instance will NOT be invoked more than once. >> >> >> >> >>>> >>>> A side suggestion: it would be nice to have finite state diagram >>>> >>>> >>>> >>>> >>to illustrate the state transition of a scope in the spec, especially >>after we pass both completionHandler and terminationHandler issue. The >>life cycle of a scope can be complicated. >> >> >> >> >>>> >>>> >>>> Thanks! >>>> >>>> >>>> Regards, >>>> Alex Yiu >>>> >>>> >>>> Satish Thatte wrote: >>>> >>>> >>>> >>>> thanks >>>> >>>> >>>> >>>> >>>>________________________________ >>>> >>>> >>>> From: Danny van der Rijn [mailto:dannyv@tibco.com] >>>> Sent: Friday, September 24, 2004 12:15 PM >>>> To: Satish Thatte >>>> Cc: wsbpel@lists.oasis-open.org >>>> Subject: Re: [wsbpel] Issue 135 - Proposal to vote >>>> >>>> >>>> >>>> i misinterpreted some subleties in the proposal. i withdraw my >>>> >>>> >>>> >>>> >>comments. >> >> >> >> >>>> >>>> Satish Thatte wrote: >>>> >>>> ?? >>>> >>>> The forcedTermination fault handler was able to do compensation. >>>> >>>> >>>> >>>> >>Why is >> >> >> >> >>>> this a change? >>>> >>>> No, the fact that the process does not have a termination >>>> >>>> >>>> >>>> >>handler is >> >> >> >> >>>> deliberate since we do not have a notion of forced termination >>>> >>>> >>>> >>>> >>of a >> >> >> >> >>>> process instance. I deliberately moved <terminate/> to <exit/> >>>> >>>> >>>> >>>> >>to make >> >> >> >> >>>> that clear. >>>> >>>> This proposal actually changes absolutely nothing semantically. >>>> >>>> >>>> >>>> >>It >> >> >> >> >>>> simply changes syntax. >>>> >>>> -----Original Message----- >>>> From: Danny van der Rijn [mailto:dannyv@tibco.com] >>>> Sent: Friday, September 24, 2004 8:31 AM >>>> To: Satish Thatte >>>> Cc: wsbpel@lists.oasis-open.org >>>> Subject: Re: [wsbpel] Issue 135 - Proposal to vote >>>> >>>> i don't like the idea of the default termination handler >>>> >>>> >>>> >>>> >>performing >> >> >> >> >>>> compensation. this part is an addition, rather than a syntactic >>>> >>>> >>>> >>>> >> >> >> >> >>>> substitution, and i think it falls on the wrong side of the >>>> >>>> >>>> >>>> >>meaning of >> >> >> >> >>>> default. >>>> >>>> also, i assume that the fact that a process doesn't have a >>>> >>>> >>>> >>>> >>termination >> >> >> >> >>>> handler is an inadvertent omission? >>>> >>>> danny >>>> >>>> Satish Thatte wrote: >>>> >>>> >>>> >>>> Overview: >>>> >>>> >>>> >>>> The bpws:forcedTermination "fault" in the current >>>> >>>> >>>> >>>> >>specification is not >> >> >> >> >>>> >>>> >>>> a normal fault. It is simply a way to permit interception of >>>> >>>> >>>> >>>> >>forced >> >> >> >> >>>> termination by a scope to perform special handling to shut the >>>> >>>> >>>> >>>> >>scope >> >> >> >> >>>> down in an orderly manner. The differences from a normal fault >>>> >>>> >>>> >>>> >>include >> >> >> >> >>>> the inability to be caught by a catchAll handler, and the >>>> >>>> >>>> >>>> >>inability to >> >> >> >> >>>> throw or rethrow any fault within the handler. It is thus >>>> >>>> >>>> >>>> >>proposed that >> >> >> >> >>>> we eliminate the notion of a bpws:forcedTermination fault from >>>> >>>> >>>> >>>> >>the >> >> >> >> >>>> specification and replace it with a notion of a special handler >>>> >>>> >>>> >>>> >>for >> >> >> >> >>>> forced termination. A secondary part of the proposal is to >>>> >>>> >>>> >>>> >>replace the >> >> >> >> >>>> <terminate/> activity with an <exit/> activity with identical >>>> >>>> >>>> >>>> >>semantics, >> >> >> >> >>>> simply to avoid terminological confusion with the notion of >>>> >>>> >>>> >>>> >>forced >> >> >> >> >>>> termination. >>>> >>>> >>>> >>>> >>>> Detailed proposal: >>>> >>>> >>>> >>>> In all the text of the specification, including section >>>> >>>> >>>> >>>> >>5 and Appendix >> >> >> >> >>>> >>>> >>>> A, eliminate the mention of bpws:forcedTermination and remove >>>> >>>> >>>> >>>> >>this token >> >> >> >> >>>> from the bpws namespace. >>>> >>>> >>>> >>>> >>>> In Sections 6.2 and 13 >>>> >>>> >>>> >>>> Replace the syntax >>>> >>>> >>>> >>>> <scope variableAccessSerializable="yes|no" >>>> >>>> >>>> >>>> >>standard-attributes> >> >> >> >> >>>> >>>> standard-elements >>>> >>>> <variables>? >>>> >>>> ... >>>> >>>> </variables> >>>> >>>> <correlationSets>? >>>> >>>> ... >>>> >>>> </correlationSets> >>>> >>>> <faultHandlers>? >>>> >>>> ... >>>> >>>> </faultHandlers> >>>> >>>> <compensationHandler>? >>>> >>>> ... >>>> >>>> </compensationHandler> >>>> >>>> <eventHandlers>? >>>> >>>> ... >>>> >>>> </eventHandlers> >>>> >>>> activity >>>> >>>> </scope> >>>> >>>> >>>> >>>> with the syntax >>>> >>>> >>>> >>>> <scope variableAccessSerializable="yes|no" >>>> >>>> >>>> >>>> >>standard-attributes> >> >> >> >> >>>> >>>> standard-elements >>>> >>>> <variables>? >>>> >>>> ... >>>> >>>> </variables> >>>> >>>> <correlationSets>? >>>> >>>> ... >>>> >>>> </correlationSets> >>>> >>>> <faultHandlers>? >>>> >>>> ... >>>> >>>> </faultHandlers> >>>> >>>> <compensationHandler>? >>>> >>>> ... >>>> >>>> </compensationHandler> >>>> >>>> <terminationHandler>? >>>> >>>> ... >>>> >>>> </terminationHandler> >>>> >>>> <eventHandlers>? >>>> >>>> ... >>>> >>>> </eventHandlers> >>>> >>>> activity >>>> >>>> </scope> >>>> >>>> >>>> >>>> In Section 13.4.2 >>>> >>>> >>>> >>>> Replace the text >>>> >>>> >>>> >>>> Scopes provide the ability to control the semantics of >>>> >>>> >>>> >>>> >>forced >> >> >> >> >>>> >>>> >>>> termination to some degree. When the activity being terminated >>>> >>>> >>>> >>>> >>is in >> >> >> >> >>>> fact a scope, the behavior of the scope is interrupted and the >>>> >>>> >>>> >>>> >>fault >> >> >> >> >>>> handler for the standard bpws:forcedTermination fault is run. >>>> >>>> >>>> >>>> >>Note that >> >> >> >> >>>> this applies only if the scope is in normal processing mode. If >>>> >>>> >>>> >>>> >>the >> >> >> >> >>>> scope has already experienced an internal fault and invoked a >>>> >>>> >>>> >>>> >>fault >> >> >> >> >>>> handler, then as stated above, all other fault handlers >>>> >>>> >>>> >>>> >>including the >> >> >> >> >>>> handler for bpws:forcedTermination are uninstalled, and the >>>> >>>> >>>> >>>> >>forced >> >> >> >> >>>> termination has no effect. The already active fault handler is >>>> >>>> >>>> >>>> >>allowed >> >> >> >> >>>> to complete. >>>> >>>> >>>> >>>> >>>> The fault handler for the bpws:forcedTermination fault >>>> >>>> >>>> >>>> >>is designed like >> >> >> >> >>>> >>>> >>>> other fault handlers, but this fault handler cannot rethrow any >>>> >>>> >>>> >>>> >>fault. >> >> >> >> >>>> Even if an uncaught fault occurs during its behavior, it is not >>>> >>>> >>>> >>>> >>rethrown >> >> >> >> >>>> to the next enclosing scope. This is because the enclosing scope >>>> >>>> >>>> >>>> >>has >> >> >> >> >>>> already faulted, which is what is causing the forced termination >>>> >>>> >>>> >>>> >>of the >> >> >> >> >>>> nested scope. >>>> >>>> >>>> >>>> >>>> In other respects this is a normal fault handler. Its >>>> >>>> >>>> >>>> >>behavior begins >> >> >> >> >>>> >>>> >>>> by implicitly (recursively) terminating all activities directly >>>> >>>> >>>> >>>> >>enclosed >> >> >> >> >>>> within its associated scope that are currently active. It can >>>> >>>> >>>> >>>> >>invoke >> >> >> >> >>>> compensate activities. And when it is missing, it is provided by >>>> >>>> >>>> >>>> >>using >> >> >> >> >>>> the same implicit behavior that is used for all other implicit >>>> >>>> >>>> >>>> >>fault >> >> >> >> >>>> handlers. >>>> >>>> >>>> >>>> >>>> Note that forced termination of nested scopes occurs in >>>> >>>> >>>> >>>> >>innermost-first >> >> >> >> >>>> >>>> >>>> order as a result of the rule (quoted above) that the behavior >>>> >>>> >>>> >>>> >>of any >> >> >> >> >>>> fault handler begins by implicitly (recursively) terminating all >>>> activities directly enclosed within its associated scope that >>>> >>>> >>>> >>>> >>are >> >> >> >> >>>> currently active. >>>> >>>> >>>> >>>> >>>> with the text >>>> >>>> >>>> >>>> Scopes provide the ability to control the semantics of >>>> >>>> >>>> >>>> >>forced >> >> >> >> >>>> >>>> >>>> termination to some degree. When the activity being terminated >>>> >>>> >>>> >>>> >>is in >> >> >> >> >>>> fact a scope, the forced termination of a scope begins by >>>> >>>> >>>> >>>> >>terminating >> >> >> >> >>>> all activities directly enclosed within its associated scope >>>> >>>> >>>> >>>> >>that are >> >> >> >> >>>> currently active. Following this, the custom termination >>>> >>>> >>>> >>>> >>handler for >> >> >> >> >>>> the scope, if present, is run. If the custom termination >>>> >>>> >>>> >>>> >>handler is >> >> >> >> >>>> missing, the default termination handler performs compensation >>>> >>>> >>>> >>>> >>of all >> >> >> >> >>>> successfully completed nested scopes in the same order as in the >>>> >>>> >>>> >>>> >>case of >> >> >> >> >>>> a default fault handler. >>>> >>>> >>>> >>>> >>>> Forced termination for a scope applies only if the scope >>>> >>>> >>>> >>>> >>is in normal >> >> >> >> >>>> >>>> >>>> processing mode. If the scope has already experienced an >>>> >>>> >>>> >>>> >>internal fault >> >> >> >> >>>> and invoked a fault handler, then the termination handler is >>>> uninstalled, and the forced termination has no effect. The >>>> >>>> >>>> >>>> >>already >> >> >> >> >>>> active fault handler is allowed to complete. >>>> >>>> >>>> >>>> >>>> The termination handler for a scope is permitted to use >>>> >>>> >>>> >>>> >>the same range >> >> >> >> >>>> >>>> >>>> of activities as a fault handler, including the <compensate/> >>>> >>>> >>>> >>>> >>activity. >> >> >> >> >>>> However, a termination handler 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 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. >>>> >>>> >>>> >>>> >>>> Forced termination of nested scopes occurs in >>>> >>>> >>>> >>>> >>innermost-first order as >> >> >> >> >>>> >>>> >>>> a result of the rule (stated above) that the termination handler >>>> >>>> >>>> >>>> >>is run >> >> >> >> >>>> after terminating all activities (including scope activities) >>>> >>>> >>>> >>>> >>directly >> >> >> >> >>>> enclosed within its associated scope that are currently active. >>>> >>>> >>>> >>>> >>>> >>>> To unsubscribe from this mailing list (and be removed >>>> >>>> >>>> >>>> >>from the roster > > >> >> >> >> >>>> >>>> >>>> of the OASIS TC), go to >>>> >>>> >>>> >>>> >>>> >>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workg >> >> >r > > >> >> >> >> >>>> oup.php. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> To unsubscribe from this mailing list (and be removed from the >>>> >>>> >>>> >>>> >>roster of the OASIS TC), go to >>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workg >> >> >r > > >>oup.php. >> >> >> >> >>>> >>>> >>>> >>>> >>>> To unsubscribe from this mailing list (and be removed from the >>>> >>>> >>>> >>>> >>roster of the OASIS TC), go to >>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workg >> >> >r > > >>oup.php. >> >> >> >> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >> >> >> >> > > >
S/MIME Cryptographic Signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]