Re: completionHandler example

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

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