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



Satish,

[It seems to me that one of my earlier reply to this email thread got lost. Anyway, I am repeating similar content here.]

(1)
It's good to know that there is no double-termination situation due to internal state/conditions of a process.

However, I guess double-termination still occurs deal to duplicated external termination requests. E.g. A person try to terminate a process gracefully with a BPEL management tool more than once. (similar to soft kill a OS process more than once) Therefore, I guess we still need to address the double termination issue by stating something similar to the following in the spec:
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.

(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.

(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_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. 

	 


  



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