Dumas, Marlon wrote:
>In order to address issue 193, the last paragraph of this quote (with
>some re-wording) could be included in the spec.
>An interesting point about the above formulation is that, while it
>precludes the activity after the join condition to be started before all
>incoming links have been determined, it does not preclude a BPEL engine
>from determining to "skip" the activity after the join condition and to
>propagate false values along its outgoing links, as soon as it can be
>determined that the truth condition will evaluate to FALSE no matter
>what. In the last paragraph of your e-mail dated 15 February Re: issue
>189, you suggested that this latter "optimization" is okay. I insist
>that the question is to determine whether this "optimization" should be
>allowed or not. If it is allowed, then the above formulation is OK (or
>the formulation that I suggested in my previous e-mail as well). If this
>optimization is not allowed, then the above formulation should be
>expanded to preclude it.
>
>
I think this optimization will be confusing, and we should not allow it.
Consider the case where activity C has the join condition 'A or B' (A
and B referring to two other activities), and activity D has the join
condition 'C'. If activity A has completed successfully, activity C must
still wait for activity B to complete, even though the link status will
not affect the decision to execute C (and subsequently D).
If C has the join condition 'A and B', and D has the join condition
'not(C)', then again activity C must wait for both A and B to complete.
However, if we allow this optimization, then as soon as activity A
completes unsuccessfully, activity D is allowed to execute, even though
activity B has not completed yet.
Assaf
>Cheers
>
>marlon
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:
>For additional commands, e-mail:
>
>
>
>
