Actually I read the thread throughly and I explicitly remember the
paragraph you refer to. Unfortunately I still do not understand what
point you are trying to make.
Race conditions exist all over the place and I see no difference between
the race condition in my first and second example even though you have
argued (if I understand your argument correctly) that the first should
be illegal while the second is fine.
I still do not understand your logic.
Yaron
Satish Thatte wrote:
>
> Yaron,
>
> You probably did not have time to read the thread thoroughly. For
> instance, I wrote below:
>
> > > > I repeat. There are races that can be detected and ones that
> > > > cannot. Your example is not a race. Non-start receives that
> > > > depend on correlation initiated by a start receive do create
> > > > a race. I am concerned about going out of our way to allow
> > > > something that clearly is a race.
> I agree that all races cannot be eliminated, although the one you showed
> can in fact be detected. I am not asking for static analysis to
> eliminate all races pessimistically. I am simply asking why we should
> clarify something in a way that almost perversely creates a race.
> Nothing very profound (sorry to disappoint you :-)).
>
> Satish
>
> *From:* Yaron Y. Goland [mailto:]
> *Sent:* Mon 9/13/2004 2:44 PM
> *To:* Ugo Corda
> *Cc:* Satish Thatte; wsbpeltc
> *Subject:* Re: [wsbpel] Issue 81 - Rough draft of proposal for vote
>
> I must admit that I don't understand the point that Satish is making. I
> believe he is arguing that we shouldn't allow for situations that could
> contain race conditions but just about all messaging situations can
> potentially enable race conditions.
>
> I've tried to boil the situation down as far as I can. Below I provide
> two examples that are different only in that one has a flow and another
> has a sequence. In so far as I'm concerned these two scenarios are
> absolutely identical in terms of their ability to cause race conditions
> and therefore there is no need to distinguish between them. I believe
> that Satish disagrees but I don't understand why. Hopefully he can use
> these two very specific examples to explain himself in a manner that
> even my intellect can grasp.
>
> scope
> flow
> receive ... createInstance="yes"
> correlations
> correlation set="foo" initiate="yes"
> receive ... createInstance="no"
> correlations
> correlation set="foo" initiate="no"
>
> and
>
> scope
> sequence
> receive ... createInstance="yes"
> correlations
> correlation set="foo" initiate="yes"
> receive ... createInstance="no"
> correlations
> correlation set="foo" initiate="no"
>
>
> Thanks,
>
> Yaron
>
>
> Ugo Corda wrote:
>
> >
> >
> > Actually a correlation set is far from being a GUID. A GUID is unique
> > and it implies that the initiator generates it and any follower would
> > only know it after receiving it from the initiator. But correlation sets
> > are just business data (e.g. customer ID) which all the parties might
> > very well know since the beginning. That is what does not prevent a
> > sender, in my mind, from sending a message to the receive at the same
> > time as the invoke is launched.
> >
> > Section 10.1 implies temporal sequence for what concerns activities
> > invocation, but it does not say anything, as far as I can see, about
> > timing of message sending.
> >
> > And as far as timing of activity invocation is concerned, in the flow
> > case with two receives, the start receive is necessarily activated first
> > (without that activation, the second receive does not even exist), and
> > it is only after that activation (and related setting of the correlation
> > set) that the non-start receive is activated. So, again, not that
> > different than the invoke/receive sequence.
> >
> > Ugo
> >
> > > -----Original Message-----
> > > From: Satish Thatte [mailto:]
> > > Sent: Friday, September 10, 2004 4:07 PM
> > > To: Ugo Corda;
> > > Cc: wsbpeltc
> > > Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
> > >
> > >
> > > The assumption underlying the correlation mechanism is that
> > > it is like a "header" with a "correlation GUID" similar to a
> > > session ID. Thus the correlation tokens are created by some
> > > one party in the correlated conversations. In particular by
> > > the party that has a send with initiate=true. The
> > > "initiator" of the correlation. The others are called
> > > "followers". See section 10.1.
> > >
> > > -----Original Message-----
> > > From: Ugo Corda [mailto:]
> > > Sent: Friday, September 10, 2004 3:57 PM
> > > To: Satish Thatte;
> > > Cc: wsbpeltc
> > > Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
> > >
> > > Sorry, I still do not see the difference. I think you are
> > > using a different set of assumptions than I do. In
> > > particular, I don't understand your statement below: "the
> > > invoke must complete all the way to its target before the
> > > message corresponding to the receive can even be sent, since
> > > the correlation tokens must be copied into it". What prevents
> > > a sender from sending a message to the receive, with the same
> > > correlation set as defined by the invoke, before the invoke
> > > itself completes, or even at the same exact time that the
> > > invoke initiates? Couldn't that message be lost in that case too?
> > >
> > > Ugo
> > >
> > > > -----Original Message-----
> > > > From: Satish Thatte [mailto:]
> > > > Sent: Friday, September 10, 2004 2:48 PM
> > > > To: Ugo Corda;
> > > > Cc: wsbpeltc
> > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
> > > >
> > > >
> > > > The difference is that the message which instantiates the
> > > > instance and initiates the correlation arrives simultaneously
> > > > with the non-start one which is dependent on the correlation.
> > > > Note that the start message is not dependent on the
> > > > correlation hence will not be lost regardless of how slow
> > > > instantiation is. The non-start message may be lost.
> > > >
> > > > This is distinct from the example below where the correlation
> > > > initiation is always before the dependent activity, and in
> > > > fact the invoke must complete all the way to its target
> > > > before the message corresponding to the receive can even be
> > > > sent, since the correlation tokens must be copied into it.
> > > >
> > > > I repeat. There are races that can be detected and ones that
> > > > cannot. Your example is not a race. Non-start receives that
> > > > depend on correlation initiated by a start receive do create
> > > > a race. I am concerned about going out of our way to allow
> > > > something that clearly is a race.
> > > >
> > > > -----Original Message-----
> > > > From: Ugo Corda [mailto:]
> > > > Sent: Friday, September 10, 2004 2:12 PM
> > > > To: Satish Thatte;
> > > > Cc: wsbpeltc
> > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
> > > >
> > > > > In your example, there is no race if the invoke is initiating the
> > > > > correlation that the other party is using for the receive.
> > > >
> > > > Same with the two initial receive's within a flow. The start
> > > > receive initiates the correlation and the non-start receive
> > > > can use that correlation.
> > > >
> > > > Ugo
> > > >
> > > > > -----Original Message-----
> > > > > From: Satish Thatte [mailto:]
> > > > > Sent: Friday, September 10, 2004 2:02 PM
> > > > > To: Ugo Corda;
> > > > > Cc: wsbpeltc
> > > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
> > > > >
> > > > >
> > > > > In your example, there is no race if the invoke is initiating the
> > > > > correlation that the other party is using for the receive.
> > > > >
> > > > > But in general, as I said, there are races that can be
> > > detected and
> > > > > ones that cannot. I am simply concerned about going out
> > > of our way
> > > > > to allow something that clearly is a race.
> > > > >
> > > > > -----Original Message-----
> > > > > From: Ugo Corda [mailto:]
> > > > > Sent: Friday, September 10, 2004 12:07 PM
> > > > > To: Satish Thatte;
> > > > > Cc: wsbpeltc
> > > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
> > > > >
> > > > > The following is also statically detectable:
> > > > >
> > > > > sequence
> > > > > invoke
> > > > > receive
> > > > > sequence
> > > > >
> > > > > Depending on the time spent executing the invoke, the receive
> > > > > message might be lost. So are we going to disallow that type of
> > > > > sequence too?
> > > > >
> > > > > Ugo
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Satish Thatte [mailto:]
> > > > > > Sent: Friday, September 10, 2004 11:55 AM
> > > > > > To: ; Ugo Corda
> > > > > > Cc: wsbpeltc
> > > > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of
> > > proposal for vote
> > > > > >
> > > > > >
> > > > > > I have a sense of déjà vu that I have seen this and
> > > replied to it
> > > > > > earlier.
> > > > > >
> > > > > > Basically, the answer is that it is possible to make process
> > > > > > protocol mistakes that would cause races that would then
> > > > risk losing
> > > > > > messages. Not all such races can be statically detected.
> > > > However,
> > > > > > non-start initial receives (assuming they are appropriately
> > > > > > correlated) are an obviously statically detectable case,
> > > > hence there
> > > > > > is no reason to allow them.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Yaron Y. Goland [mailto:]
> > > > > > Sent: Friday, September 10, 2004 10:54 AM
> > > > > > To: Ugo Corda
> > > > > > Cc: Satish Thatte; wsbpeltc
> > > > > > Subject: Re: [wsbpel] Issue 81 - Rough draft of
> > > proposal for vote
> > > > > >
> > > > > > I agree with Ugo. I don't see the difference. What makes it
> > > > > > 'explicitly impossible' to expect that such a message
> > > > would arrive?
> > > > > > In fact, how is
> > > > > > it any different than a start receive immediately followed by a
> > > > > > non-start receive? The behavior in the BPEL sense would
> > > > > > appear to me to
> > > > > > be identical.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Yaron
> > > > > >
> > > > > > Ugo Corda wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > Yes except in the latter case we have some
> > > > expectation of a >
> > > > > > > protocol to make sure messages don't arrive too early.
> > > > > > >
> > > > > > > I cannot see the difference. The activation of a
> > > > > > non-initial receive
> > > > > > > is dependent on the completion of the preceding
> > > > activities in the
> > > > > > > sequence, which can be completely run-time dependent. The
> > > > > > activation
> > > > > > > of an initial non-start receive is dependent on the
> > > > > > reception of the
> > > > > > > initial start receive, which can also be completely run-time
> > > > > > > dependent. I don't see how any protocol could do better
> > > > > in one case
> > > > > > > than in the other.
> > > > > > >
> > > > > > > Ugo
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Satish Thatte [mailto:]
> > > > > > > > Sent: Tuesday, August 31, 2004 10:15 AM
> > > > > > > > To: Ugo Corda;
> > > > > > > > Cc: wsbpeltc
> > > > > > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal
> > > > > > for vote
> > > > > > > > >
> > > > > > > > Yes except in the latter case we have some
> > > > expectation of a >
> > > > > > > protocol to make sure messages don't arrive too early.
> > > > In > the
> > > > > > > initial non-start receive this is explicitly
> > > > impossible. > I am
> > > > > > > just saying that we can interpret this at a technical >
> > > > > level but I
> > > > > > > wonder if it is really meaningful. Not a huge > deal but my
> > > > > > > preference is to tighten the features so we can >
> > > > justify their
> > > > > > > usage. >
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Ugo Corda [mailto:]
> > > > > > > > Sent: Tuesday, August 31, 2004 10:10 AM
> > > > > > > > To: Satish Thatte;
> > > > > > > > Cc: wsbpeltc
> > > > > > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of
> > > > > proposal for vote
> > > > > > > >
> > > > > > > > I imagine that would be not different than the case of a >
> > > > > > > non-initial receive to which a message is sent before the >
> > > > > > > receive itself is activated. It would be up to the >
> > > > > > > implementation to decide whether to cache the message
> > > > > or drop it.
> > > > > > > >
> > > > > > > > Ugo
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Satish Thatte [mailto:] > >
> > > > > > > Sent: Tuesday, August 31, 2004 9:40 AM > > To: Ugo Corda;
> > > > > > > > > Cc: wsbpeltc
> > > > > > > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of
> > > > > > proposal for vote
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Suppose such an activity is a receive. How would
> > > > > the message
> > > > > > > > > be correlated to the instance without danger of being
> > > > > lost if >
> > > > > > > > it arrived "too soon"? > >
> > > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Ugo Corda [mailto:]
> > > > > > > > > Sent: Tuesday, August 31, 2004 9:31 AM
> > > > > > > > > To: Satish Thatte;
> > > > > > > > > Cc: wsbpeltc
> > > > > > > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of
> > > > > > proposal for vote
> > > > > > > > >
> > > > > > > > > It would probably be easier if you could explain why
> > > > > those > >
> > > > > > > activities should be banned. What kind of problems do you
> > > > > > > think
> > > > > > > they would create? > >
> > > > > > > > > Ugo
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Satish Thatte
> > > > [mailto:] > > >
> > > > > > > Sent: Monday, August 30, 2004 10:47 PM > > > To: Ugo Corda;
> > > > > > > > > > Cc: wsbpeltc
> > > > > > > > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of
> > > > > > proposal for vote
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Help me understand why we should allow initial
> > > > > non-start >
> > > > > > > activities? > > > Why not ban those?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Ugo Corda [mailto:]
> > > > > > > > > > Sent: Friday, August 27, 2004 8:04 PM
> > > > > > > > > > To:
> > > > > > > > > > Cc: wsbpeltc
> > > > > > > > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of
> > > > > > proposal for vote
> > > > > > > > > >
> > > > > > > > > > Your new wording works for me!
> > > > > > > > > >
> > > > > > > > > > Thank you,
> > > > > > > > > > Ugo
> > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: Yaron Y. Goland
> > > [mailto:] > > > >
> > > > > > > Sent: Friday, August 27, 2004 3:39 PM > > > > To: Ugo Corda
> > > > > > > > > > > Cc: wsbpeltc
> > > > > > > > > > > Subject: Re: [wsbpel] Issue 81 - Rough draft of >
> > > > > > > proposal for vote > > > >
> > > > > > > > > > >
> > > > > > > > > > > An excellent point. So long as we require
> > > that all >
> > > > > > > processes MUST > > > > have at least one start activity then
> > > > > > > initial
> > > > > > activities can be
> > > > > > > > > > > anything.
> > > > > > > > > > >
> > > > > > > > > > > Below is my modified rough draft of a proposal
> > > > > to vote: >
> > > > > > > > > > > > > > Section 6.4
> > > > > > > > > > >
> > > > > > > > > > > Change: To be instantiated, each business
> > > > process must >
> > > > > > > contain at > > > > least one such "start activity."
> > > > This must be
> > > > > > > an initial > > activity in
> > > > > > > > > > > the sense that there is no basic activity that
> > > > logically
> > > > > > > > > precedes it
> > > > > > > > > > > in the behavior of the process.
> > > > > > > > > > >
> > > > > > > > > > > To: To be instantiated, each business
> > > process must > >
> > > > > > > contain at least > > > > one such "start activity."
> > > That is, a
> > > > > receive/pick activity
> > > > > > > > > > > annotated with a createInstance="yes"
> > > > attribute. See >
> > > > > > > section 11.4 > > > > for more details on start
> > > activities. > >
> > > > > > > > > > > > > Section 11.4
> > > > > > > > > > >
> > > > > > > > > > > Change: A receive activity annotated in this
> > > > way MUST be
> > > > > > > > > an initial
> > > > > > > > > > > activity in the process, that is, the only
> > > other basic
> > > > > > > > activities > > > > may potentially be performed
> > > prior to or
> > > > > > > simultaneously > > with such a
> > > > > > > > > > > receive activity MUST be similarly annotated
> > > > > > receive activities.
> > > > > > > > > > >
> > > > > > > > > > > To: A receive/pick activity annotated in this
> > > > > way MUST be
> > > > > > > > > a "start > > > > activity". A "start activity" is
> > > > an initial
> > > > > > activity that has a
> > > > > > > > > > > createInstance="yes" attribute defined on it. An
> > > > > initial >
> > > > > > > > activity is > > > > a receive/pick activity where no other
> > > > > > > activities but > > scope, flow,
> > > > > > > > > > > sequence and empty activities occur before it in
> > > > > > the process's
> > > > > > > > > > > execution path. While all start activities must
> > > > > be initial
> > > > > > > > > > > activities not all initial activities are required
> > > > > > to be start
> > > > > > > > > > > activities. If
> > > > > > > > > > an initial
> > > > > > > > > > > activity is not a start activity then the
> > > > > initial activity
> > > > > > > > > > will only > > > > become active when it is inside of a
> > > > > > > process instance. > > > >
> > > > > > > > > > > Change: It is permissible to have the
> > > > createInstance > >
> > > > > > > attribute set > > > > to "yes" for a set of
> > > concurrent initial
> > > > > > > activities. > > > >
> > > > > > > > > > > To: It is permissible to have multiple start
> > > > activities.
> > > > > > > > > > >
> > > > > > > > > > > Change: All such receive activities MUST use
> > > the same
> > > > > > > > correlation > > > > sets (see Correlation).
> > > > > > > > > > >
> > > > > > > > > > > To: If a process has multiple start
> > > activities then all
> > > > > > > > the start
> > > > > > > > > > > activities MUST use the same correlation sets (see
> > > > > > > > > > Correlation).
> > > > > > > > > > >
> > > > > > > > > > > Ugo Corda wrote:
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > and only receive/pick in
> > > > > > > > > > > > > addition to the previously listed
> > > > > activities MAY occur
> > > > > > > > > > > in parallel
> > > > > > > > > > > > with > it in the process's execution
> > > path. > > > >
> > > > > > > > > > > > > Why limit it to other receive/pick
> > > > activities? If the
> > > > > > > > > following is > > > > > allowed
> > > > > > > > > > > >
> > > > > > > > > > > > <flow>
> > > > > > > > > > > > <receive createInstance="yes".../>
> > > > > > > > > > > > <receive createInstance="no".../>
> > > > > > > > > > > > </flow>
> > > > > > > > > > > >
> > > > > > > > > > > > then why not also allow this:
> > > > > > > > > > > >
> > > > > > > > > > > > <flow>
> > > > > > > > > > > > <receive createInstance="yes".../>
> > > > > > > > > > > > <invoke .../>
> > > > > > > > > > > > </flow>
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Ugo
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > To unsubscribe from this mailing list (and be
> > > > > > removed from the
> > > > > > > > > > roster of the OASIS TC), go to
> > > > > > > > > >
> > > > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> > > > > > > > > ave_workgr
> > > > > > > > > oup.php.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > To unsubscribe from this mailing list (and be
> > > > > removed from > >
> > > > > > > the roster of the OASIS TC), go to > >
> > > > > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> > > > > > > > ave_workgr
> > > > > > > > oup.php.
> > > > > > > >
> > > > > > > >
> > > > > > > > To unsubscribe from this mailing list (and be removed
> > > > > from > the
> > > > > > > roster of the OASIS TC), go to >
> > > > > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> > > > > > > ave_workgr
> > > > > > > oup.php.
> > > > > > >
> > > > > >
> > > > >
> > > > > To unsubscribe from this mailing list (and be removed from the
> > > > > roster of the OASIS TC), go to
> > > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> > > > ave_workgroup.php.
> > > >
> > > >
> > >
> >
>
