[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 81 - Rough draft of proposal for vote
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:ygoland@bea.com] > *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:satisht@microsoft.com] > > > Sent: Friday, September 10, 2004 4:07 PM > > > To: Ugo Corda; ygoland@bea.com > > > 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:UCorda@SeeBeyond.com] > > > Sent: Friday, September 10, 2004 3:57 PM > > > To: Satish Thatte; ygoland@bea.com > > > 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:satisht@microsoft.com] > > > > Sent: Friday, September 10, 2004 2:48 PM > > > > To: Ugo Corda; ygoland@bea.com > > > > 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:UCorda@SeeBeyond.com] > > > > Sent: Friday, September 10, 2004 2:12 PM > > > > To: Satish Thatte; ygoland@bea.com > > > > 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:satisht@microsoft.com] > > > > > Sent: Friday, September 10, 2004 2:02 PM > > > > > To: Ugo Corda; ygoland@bea.com > > > > > 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:UCorda@SeeBeyond.com] > > > > > Sent: Friday, September 10, 2004 12:07 PM > > > > > To: Satish Thatte; ygoland@bea.com > > > > > 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:satisht@microsoft.com] > > > > > > Sent: Friday, September 10, 2004 11:55 AM > > > > > > To: ygoland@bea.com; 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:ygoland@bea.com] > > > > > > 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:satisht@microsoft.com] > > > > > > > > Sent: Tuesday, August 31, 2004 10:15 AM > > > > > > > > To: Ugo Corda; ygoland@bea.com > > > > > > > > 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:UCorda@SeeBeyond.com] > > > > > > > > Sent: Tuesday, August 31, 2004 10:10 AM > > > > > > > > To: Satish Thatte; ygoland@bea.com > > > > > > > > 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:satisht@microsoft.com] > > > > > > > > > Sent: Tuesday, August 31, 2004 9:40 AM > > To: Ugo Corda; > > > > > > > ygoland@bea.com > > 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:UCorda@SeeBeyond.com] > > > > > > > > > Sent: Tuesday, August 31, 2004 9:31 AM > > > > > > > > > To: Satish Thatte; ygoland@bea.com > > > > > > > > > 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:satisht@microsoft.com] > > > > > > > > > > Sent: Monday, August 30, 2004 10:47 PM > > > To: Ugo Corda; > > > > > > > ygoland@bea.com > > > 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:UCorda@SeeBeyond.com] > > > > > > > > > > Sent: Friday, August 27, 2004 8:04 PM > > > > > > > > > > To: ygoland@bea.com > > > > > > > > > > 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:ygoland@bea.com] > > > > > > > > > > > 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. > > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]