Re: completionHandler example

["Yaron Y. Goland" <ygoland@bea.com>]

But Satish, that is exactly what my example does. Could you please be 
more specific in identifying the point of failure?
	Thanks,
		Yaron

Satish Thatte wrote:
> 
> 
> That doesn't work if you want to do cascading completions aka named
> completions.
> 
> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com]
> Sent: Thursday, September 30, 2004 11:17 AM
> To: Satish Thatte
> Cc: wsbpeltc
> Subject: Re: completionHandler example
> 
> I realize why putting the completion handler logic before the complete
> doesn't work but why doesn't putting it after the completion handler
> work?
> 
> scope
>     variables
>        variable name="MessageTrackerVariable"...
>     sequence
>        scope wrapper
>           flow
>              scope A_end_in_complete_to_wrapper
>                 ...
>              scope B_end_in_complete_to_wrapper
>                 ...
>              scope C_end_in_complete_to_wrapper
>                 ...
>        scope CompletionHandler
>           (Check MessageTrackerVariable and see if any cleanup is
> needed)
> 
> Because the exit point of a completed scope is always well defined can't
> 
> the completion handler logic be placed after the completed scope?
> 
>         Yaron
> 
> 
> Satish Thatte wrote:
>  >
>  >
>  > Yaron,
>  > 
>  > During the F2F you asked for a completionHandler example.  Here is my
>  > try with some explanations.  Please let me know if this makes sense to
> you.
>  >
>  > 
>  > Satish
>  > 
>  >
>  > The completionHandler is the common process logic required at all
> points
>  > of premature completion within a scope.  The only difference between
>  > copying it just before each occurrence of a <complete/> activity thus
>  >
>  > 
>  >
>  > <sequence>
>  >
>  >     <completionHandler logic>
>  >
>  >     <complete/>
>  >
>  > </sequence>
>  >
>  > 
>  >
>  > and the proposed completionHandler feature is that the
> completionHandler
>  > logic executes *after* termination of all activities in the
> prematurely
>  > completed scope.  Thus it is a pure macro if the prematurely completed
> 
>  > scope does not contain concurrent activities.  Many examples of the
> use
>  > of premature completion, e.g., completion of N out of M activities in
> a
>  > flow, do involve concurrency.  Consider a case where M suppliers had
>  > been contacted concurrently and the process was waiting for
> asynchronous
>  > responses (forgive the use of the word :-)) from them.  After at least
> N
>  > of them send responses the scope completes.  Suppose the conversation
>  > with each supplier is wrapped in a scope and a terminationHandler is
>  > used to inform a supplier whose conversation was forcibly terminated
>  > that their response is not needed.  But perhaps we did not or could
> not
>  > ensure that *exactly* N replies arrive because the race was too tricky
> 
>  > to control.  Thus it is possible that more than N responses arrived. 
>  > The completion handler could detect this situation, pick the N we
> really
>  > want and inform the rest that their responses have been rejected so
> that
>  > we exit the scope cleanly with exactly N accepted responses.
>  >
>