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 147 - Proposal For Vote



> *[a] *
> In the current text of the spec, we do NOT explicitly state that whether the 
> compensation handler of scope "A1" is supposed to undo the work of eventHandlers 
> for "cancel" from "buyer".
> _One way or the other: we SHOULD state that explicitly. _
> 

The spec states "event handlers are considered a part of the normal 
processing of the scope, i.e., active event handlers are concurrent 
activities within the scope." Perhaps we could make the point clearer 
but it is there.

> That's why I prefer:
> 
>     * having a <scope> as the child activity of eventHandlers, OR,
>     * or have eventHandler based "tScope" syntax. (I believe that is what Assaf
>       mentioned before.)
> 

The event handler model is - all instances of event handlers are exactly 
identical to having a flow that contained each event handler instance as 
a child. All fault and compensation semantics follow from that.

[Alex discusses the 'trap' of using inline compensation handlers on invokes]

I don't agree that this is an easy mistake to make so I don't think 
there is an issue to be resolved.

> *[3]*
> Back to the parallel for each discussion:
> Actually, I have difficulty in coming up meaning-rich examples of a 
> parallel-foreach without using scope as a child activity. Because, most typical 
> parallel-foreach naturally needs a local partnerLink or local variables to hold 
> the "output" or "intermediate" result of individual branches. Without using a 
> <scope> as a child activity, both forward-work within the sequence within the 
> for-each and the backward work in compensation handler becomes unnecessarily 
> complicated and prone to buggy. (If you guys really need an example to be 
> convinced about my point, I would be happy to do so in my next email)
> 

The iterator is a local variable and in cases where one is using 
for-each to just iterate over a value no partnerLinks are needed. 
Besides, one can always use a partnerLink from outside of the for-each, 
especially for serial for-each. So I therefore disagree with your 
assertion that for-each isn't useful without a scope.

> Ok. Let's say we have an extreme simple parallel-foreach which does not need any 
> local partnerLink or variables.
> 
> <scope name="A3">
>   ...
>   <sequence>
>      ...
>      <foreach iteratorVariableName="POVar"
>         iteratorVariableType="..." parallel="yes">
>          <expression>for_each_element_in_the_list_of_POs</expression>
>                   <invoke partnerLink="Seller" operation="syncSendPO" 
> inputVariable="POVar" ... />
>      </foreach>
>      ...
>   </sequence>
>   ...
> </scope>
> 
> The very same problem that I described in [1] for eventHandler occurs again for 
> "POVar" the iteratorVariable. What is the lifetime of "POVar"? How do we handle 
> the "scope snapshot" aspect for these "POVar" for compensation handler of scope 
> "A3"?
> 

POVar is scoped to foreach and only visible as long as the foreach is 
visible.

> 
> 
> Thanks!
> 
> 
> 
> 
> Regards,
> Alex Yiu
> 
> 
> 



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