RE: completionHandler example

["Satish Thatte" <satisht@microsoft.com>]

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