Hi, Yaron and others,
I agree with the concern of Edwin and Satish. We should define a
general
mechansim to express early completion condition. Then, define the
"orJoin" attribute or other syntax as a macro/special syntax short cut.
If you guys don't mind, I can supplement some alternative ideas to this
issue. I am in the thinking-out-loud mode again. That means, I need to
verify whether this idea makes sense to other people at Oracle. [ But,
as Ron said, this thinking-out-loud mode has worked quite well for me
in the past. ;-) ]
We should allow a <completeCondition> subelement attached to
parallel-flow-starter activity (e.g. <flow> or future potential
parallel <forEach>).
Syntax of completeCondition:
It has two forms:
(1) <completeCondition>a_boolean_expr</completeCondition>
(2) <completeCondition minFlow="a_number" />
... or ...
<completeCondition
countMinFlow="yes">a_number_expr</completeCondition>
The first form is the most generic form of completion condition.
The second form provides a convienent shorthand to achieves the N out
of M semantics.
The suggested orJoin="yes" is equivalent to:
<flow>
<completeCondition minFlow="1" />
...
</flow>
Semantics of completeCondition:
The complete condition will be evaluated at the completion of each
flow. If the condition is true, a standard fault
bpws:earlyCompletionFault will be signaled to other incomplete flow
activities. Each incomplete flow activity can potentially be
compensated if each flow is a scope activity. (Potentially, we can add
static analysis to enforce that when a completionCondition is used in
<flow>, <scope> must be used as activities within the
flow.)
The completeCondition itself is executed in the same scope context of
the <flow> activity. [ And, the completeCondition should be
executed serially, to avoid racing condition among flows (?)]
I hope this rough draft of ideas serves as a good base of discussion
for this issue.
Thanks!
Regards,
Alex Yiu
Satish Thatte wrote:
I echo
Edwin’s second question. Yaron,
your proposal clearly doesn’t address the intent of 6. It seems too
narrow to just
address this corner case of completion of one among many (corner case
from my
perspective).
Satish
Hi
Yaron,
2
questions:
1)
are we sure that termination is the desired behavior for the non
completed
activity?
2)
what happens if the join rule is: "the first search result which is non
empty or includes at least 3 entries with more than 85% accuracy"? The
point here is that a lot of join patterns might have logic in them. I
know that
in the past we talked about having something like <break> for
flow. (This
is something that a lot of our customers are asking us and might
address the
same us case is a more flexible way specially if the <break> can
be
configure to tell the engine to compensate or terminate).
Best,
Edwin
|