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: completionHandler example

That doesn't work if you want to do cascading completions aka named

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

       variable name="MessageTrackerVariable"...
       scope wrapper
             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

Because the exit point of a completed scope is always well defined can't

the completion handler logic be placed after the completed scope?


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
> Satish
> The completionHandler is the common process logic required at all
> 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
> logic executes *after* termination of all activities in the
> completed scope.  Thus it is a pure macro if the prematurely completed

> scope does not contain concurrent activities.  Many examples of the
> of premature completion, e.g., completion of N out of M activities in
> flow, do involve concurrency.  Consider a case where M suppliers had 
> been contacted concurrently and the process was waiting for
> responses (forgive the use of the word :-)) from them.  After at least
> 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
> 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
> want and inform the rest that their responses have been rejected so
> we exit the scope cleanly with exactly N accepted responses.

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