Yet another case
that just came to my mind (similar to what we have been discussing, even though
the premises are different). I have multiple instances of the same process,
and each instance was correctly initialized with its own c-set value. Now all
the instances are waiting on the same receive which has no c-set.
What happens? (I don't think we say anything explicit right now about cases like
this).
Ugo
The pattern you cited was banned
in a previous message in this thread. To reiterate, we could add the following
constraint:
An initiating <receive> that does
not initialize a correlation-set must be followed (in the process graph) by an
<invoke> that does initialize a c-set, before any other <receive>
or <onMessage> activities. This must be verified by static analysis of
the <process> graph.
Before a correlation-set
is "used" (that is, initiate = "no") in a process graph, it must be
"initialized" (that is, initiate = "yes") . This must be verified by static
analysis of the process.
This wording doesn't
address the use of multiple correlation sets properly, but is easier to
understand. As in my previous message, I wasn't trying to create text for
inclusion in the spec; I was trying to illustrate a simple idea. I'm sure we
could wordsmith this all into spec-ese, once we've settled on the ideas we
want to capture.
-Ron
Ugo Corda wrote:
Ron,
I don't think
your wording would be sufficient. It does not say anything about the
case of non-initiating receive's without correlation sets (which, according
to your previous note, should not be allowed when the initiating receive has
no correlation set).
It also would
allow the following sequence:
initiating
receive with no correlation set
...
receive
initiate="yes"
...
receive
initiate="no"
...
which does not
make much sense.
Ugo
Ugo,
I would phrase
this as follows:
Before a correlation set is
"used" (that is, initiate = "no") in a process graph, it must be
"initialized" (that is, initiate = "yes") . This must be verified by
static analysis of the process.
This is similar
to our rules about initialization of variables before they are used. I
have avoided using <receive> in this, because csets can be
initialized in other activities in the process.
-Ron
Ugo
Corda wrote:
Ron,
Let me see
if I correctly understand what you are proposing. You are saying that,
whenever a process has an initial <receive> with no correlation
set, the only other receive's allowed in that process are those that
have an associated correlation set, and which also are preceded at
run-time (in a way determinable by static analysis) by an activity
(other than receive - e.g. invoke) that initiates the value of that
correlation set. All other receive's (e.g. receive's with no correlation
set, or receive's whose temporal relationship with correlation set
initialization activities can only be determined at run-time) are not
allowed.
Is that a
correct interpretation of your proposal?
Thank
you,
Ugo
Ugo,
I think what
you are describing is an indeterminant process, caused by the
concurrency introduced by the flow. A static analysis could reveal
this.
<receive>
<flow>
<receive><cset initiate = "yes">
<receive><cset initiate =
"no">
As you pointed out, if this wasn't
found by static analysis, a run-time error could occur, if the
receives were executed in the wrong
order.
-Ron
|