← Prev in month
← Prev in thread
request to open sub issue 6.3 and 6.4
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"
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"
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
Title: Partial Termination and Expression Evaluation
"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
← Prev in month
← Prev in thread