I must admit that I am unclear as to what problem issue 6.3 is addressing.
Yaron
Alex Yiu wrote:
> Hi, all,
>
> We discovered two "groundwork" issues that we need to resolve no matter whether
> we want to standardize "early completion" features in the spec. Those issues
> already exist in the spec as of today.
>
> Here I request to open two sub-issues:
>
> * Issue 6.3 - "Partial Termination of a Scope"
> o One question was highlighted when we were discussing whether an
> early-completion-enabled <flow> must use <scope>-based activities as
> branch activities. That question can be translated into whether we
> actually allow a "partial termination of a scope". The spec does not
> have a clear "yes" or "no" answer as of this moment. Regardless of
> whether we standardize early completion features or how early
> completion features look like, we must answer that "yes/no" question
> and add clarification accordingly.
> * Issue 6.4 - "Concurrency and Expression Evaluation"
> o During discussion of Issue 6.*, someone expressed the concern of
> potential racing condition situation for <completionConditon>. Yes,
> there would be potential racing conditions. However, by thinking it
> deeper, racing condition actually apply to ALL expressions
> evaluation under a <flow>, whenever data underlying expressions are
> mutable. Racing-related expressions include any boolean condition
> (e.g. a <while> or if-then-else boolean condition). The more
> interesting case is transition conditions of control links, which
> actually can be used to emulate some of <completionCondition>
> functionality in some cases and face a similar racing condition problem.
>
>
> The suggested changes in attached document will serve as proposals to Issue 6.3
> and 6.4.
>
> Thanks!
>
>
> Regards,
> Alex Yiu
>
>
>
> ------------------------------------------------------------------------
>
>
> "Groundwork" Issues related to Early Completion
>
>
> Last modified: May 31, 2005 - 11 am PDT
>
> We discovered two "groundwork" issues that we need to resolve no matter whether
> we want to standardize "early completion" features in the spec. Those issues
> already exist in the spec as of today.
>
>
> [I] Partial Termination of a Scope
>
>
> Summary
> One question was highlighted when we were discussing whether an
> early-completion-enabled <flow> must use <scope>-based activities as branch
> activities. That question can be translated into whether we actually allow a
> "partial termination of a scope". The spec does not have a clear "yes" or "no"
> answer as of this moment. Regardless of whether we standardize early completion
> features or how early completion features look like, we must answer that
> "yes/no" question and add clarification accordingly.
>
> Actual Changes
> [a]
> Assuming we take Satish's interpretation of the spec which allows the "partial
> termination of scope".
>
> In Section "13.4.4. Semantics of Activity Termination"
>
> After the paragraphs of scope-termination description:
> -------------------------
> Scopes provide the ability to control the semantics of forced termination to
> some degree. ...
> ...
> Forced termination of nested scopes occurs in innermost-first order as a result
> of the rule (stated above) that the termination handler is run after terminating
> all activities (including scope activities) directly enclosed within its
> associated scope that are currently active.
> -------------------------
>
> ADD the following paragraphs:
> -------------------------
> An activity is typically terminated through its directly enclosing scope
> resulted from executing the fault handler of an ancestor scope. It is
> noteworthy that WS-BPEL DOES allow that an activity is terminated directly
> without going through its directly enclosing scope. This enable a finer-grain
> process logic termination through either a business process managment tool
> (outside of the scope of this specification) or a programmatic construct applied
> to WS-BPEL code (e.g. an early completion mechanism.) This termination situation
> is termed as "partial termination of a scope".
>
> When such a situation happens, the termination handler of the scope will NOT be
> necessarily triggered. If there are still other active concurrent activities
> running within the enclosing scope, the termination handler of the scope would
> NOT be triggered. Vice versa, if the activity being terminated is an activity of
> the last / only active flow within the enclosing scope, the termination handler
> of the scope would be triggered.
> -------------------------
>
> [AYIU: Side note: even though we mention the term "early completion", it does
> not have any implication whether we pass Issue 6.2 or not.]
>
> [b]
> If we do not want to allow "partial termination of a scope", we will ADD the
> following paragraph instead:
> -------------------------
> An activity can ONLY be terminated through its directly enclosing scope
> (typically resulted from executing the fault handler of an ancestor scope). An
> individual non-scope-based activity cannot be terminated without having its
> enclosing scope being faulted or terminated.
> -------------------------
>
>
> [II] Concurrency and Expression Evaluation
>
>
> Summary:
> During discussion of Issue 6.*, someone expressed the concern of potential
> racing condition situation for <completionConditon>. Yes, there would be
> potential racing conditions. However, by thinking it deeper, racing condition
> actually apply to ALL expressions evaluation under a <flow>, whenever data
> underlying expressions are mutable. Racing-related expressions include any
> boolean condition (e.g. a <while> or if-then-else boolean condition). The more
> interesting case is transition conditions of control links, which actually can
> be used to emulate some of <completionCondition> functionality in some cases and
> face a similar racing condition problem.
>
> Hence, this racing condition problem is actually a generic one that we need to
> solve regardless whether we have early completion features.
>
> I propose to extend the semantics of Issue 166 from just covering <assign> to
> expression evaluation as well:
> http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue166
>
> Rationale:
> The rationale is the same as Issue 166.
> Consider this example:
>
> <flow name="f1">
> <scope name="s1" isolated="yes">
> <flow name="f2">
> <while name="loop1">
> <condition>
> ($creditLine > $poAmt
> and pf:creditScore($buyerID) > 600)
> or
> $poAmt < 10000
> </condition>
> ...
> </while>
> <while name="loop2"> ... </while>
> </flow>
> </scope>
> <scope name="s2" isolated="yes"> ... </scope>
> </flow>
>
> If we don't apply the requirement of "as-if-only-logic-being-executed" to
> expression evaluation, we may face a situation where the boolean condition of
> <while> is evaluated in an interweaved fashion. The evaluation is based more
> than parts of more than one versions of snapshot along the timeline. The
> evaluation may not be true at all at any particular points of timeline.
>
> Given the restriction of nested isolated scopes, we do not have appropriate
> tools to avoid such a situation without extending Issue 166 here.
>
>
> Actual Changes:
>
> Change the title of Section 14.3:
> FROM:
> ---------------------
> 14.3. Assignment
> ---------------------
> TO:
> ---------------------
> 14.3. Assignment and Execution of Expression and Query
> ---------------------
>
> After the following paragraph in Section 14.3:
> -------------------------
> The second extension defines the behavior of assignment in the presence of
> failure during execution. The assign activity is treated as if it were atomic.
> This means that the assign activity MUST be executed as if, for the duration of
> its execution, it was the only activity in the process being executed. The
> mechanisms used to implement the previous requirement are implementation
> dependent.An important characteristic of assignment in BPEL4WSWS-BPEL is that
> assignment activities are atomic. If there is any fault during the execution of
> an assignment activity, the destination variables are left unchanged as they
> were at the start of the activity. This applies regardless of the number of
> assignment elements within the overall assignment activity.
> -------------------------
>
> ADD a new paragraph:
> -------------------------
> Similar to an assign activity, the expression or query used in a WS-BPEL
> activity (e.g. the boolean condition expression in <while>) MUST be executed, as
> if, for the duration of execution of expression or query, it was the only piece
> of logic in the WS-BPEL process being executed.
> -------------------------
>
>
> END
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
