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] Issue 135 - Proposal to vote


Premature completion (with my proposed <complete/> activity) would cause termination of all activities including nested scopes in the prematurely terminated scope.  For the nested scopes this would be caught by the termination handler.  If the completion handler of the prematurely completed scope wrere to fault, this would cause that scope to fault causing a termination of all activities in it.
 
But I think I "misspoke" on the double termination, since the completion handler would only run after all activities in the main scope had been properly terminated.  So Alex is right, after all.

________________________________

From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Mon 9/27/2004 5:33 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:

> 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.
>
I'm having a problem understanding this sentence.

Do you mean that completion of a scope entails forceful termination of
that scope, and so it can be terminated multiple times, once from the
complete activity and once from the fault? My understanding was that
completion of a scope is separate from termination, completion of a
scope may entail termination of nested scopes.

Or, could the completion handler be invoked in the scope while nested
scopes are still performing some work (e.g. their termination handlers
are still in progress)? It would be hard to define a completion handler
for a scope not knowing that its invocation occurs after all other work
in the scope has completed.

Assaf

> 
>
> ------------------------------------------------------------------------
>
> *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 <mailto: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 <mailto: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_workgr
>
>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_workgroup.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_workgroup.php.
>
>
> 
>


--
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.





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