[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Re: [wsbpel-spec-edit] Editing team issue - EventHandlerund Concurrency?
It seems like we just can't agree on what this language will do. I'm not sure what else to do at this point but to say that I object to its inclusion and ask that this be opened as an issue in the TC. Thanks, Yaron Satish Thatte wrote: > Exactly. Thanks Paco. I meant to reply but it slipped through the > many cracks. > > -----Original Message----- > From: Francisco Curbera [mailto:curbera@us.ibm.com] > Sent: Monday, January 24, 2005 10:37 PM > To: ygoland@bea.com > Cc: Dieter Koenig1; Satish Thatte; wsbpel@lists.oasis-open.org; > wsbpel-spec-edit@lists.oasis-open.org > Subject: Re: [wsbpel] Re: [wsbpel-spec-edit] Editing team issue - > EventHandler und Concurrency? > > I think Satish was referring to engine managed EPRs, not correlations. > As I > understand 139 it is about how the engine will manage the binding of > partner links. This is somewhat related but different and much more > generic > than the problem Dieter raised: the possible violation of the "at most > one" > outstanding request constraint by concurrently executing event handlers. > > Paco > > > > > > > "Yaron Y. Goland" > > <ygoland@bea.com> To: Dieter Koenig1 > <dieterkoenig@de.ibm.com> > > cc: Satish Thatte > <satisht@microsoft.com>, Francisco Curbera/Watson/IBM@IBMUS, > > 01/21/2005 06:48 > wsbpel@lists.oasis-open.org, wsbpel-spec-edit@lists.oasis-open.org > > PM Subject: Re: [wsbpel] > Re: [wsbpel-spec-edit] Editing team issue - EventHandler und > Concurrency? > Please respond to > > ygoland > > > > > > > > Huh? Where did engine managed correlations come from? Please review my > letter on 1/20/2005 included below. It states, I thought, quite clearly > exactly what issue I thought you may be addressing and explains why I > object to the currently proposed language. No where in there did I mean > to address or even imply anything about engine managed correlations. > > Now I'm just confused, > > Yaron > > Dieter Koenig1 wrote: > > > > > > > > This is correct, it was not meant to be linked to 139. > > Kind Regards > > DK > > > > > > > > > > > "Satish Thatte" > > > <satisht@microsof > > > t.com> > To > > <ygoland@bea.com> > > > 20.01.2005 14:39 > cc > > "Francisco Curbera" > > > <curbera@us.ibm.com>, > > > > <wsbpel-spec-edit@lists.oasis-open. > > org>, > > > <wsbpel@lists.oasis-open.org>, > > > Dieter > Koenig1/Germany/IBM@IBMDE > > > > Subject > > RE: [wsbpel] Re: > [wsbpel-spec-edit] > > Editing team issue - > EventHandler > > > und Concurrency? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My understanding is that there was no intent to address 139 (engine > > managed EPRs etc). Dieter and Paco, please confirm. > > > > -----Original Message----- > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > Sent: Thursday, January 20, 2005 1:12 PM > > To: Satish Thatte > > Cc: Francisco Curbera; wsbpel-spec-edit@lists.oasis-open.org; > > wsbpel@lists.oasis-open.org > > Subject: Re: [wsbpel] Re: [wsbpel-spec-edit] Editing team issue - > > EventHandler und Concurrency? > > > > If I understand your point you are saying that what you want to > clarify > > is that each instance of an event handler is unique in the sense that > > any variables defined inside of the event handler is independent from > > those defined in any other event handlers? I did not get this > > distinction from the proposed text. > > > > This would be different than issue 139 which addresses the uniqueness > of > > > > the partnerLink that received the message that triggered an event > > handler instance. > > > > If in fact the distinction I draw above accurately describes your > > intentions then I would ask that the proposed text to be re-written to > > more forcefully point out this difference. > > > > Thanks, > > > > Yaron > > > > Satish Thatte wrote: > > > This text only applies to partnerLink decls local to the event > > handler, > > > which can only be initialized independently in individual copies of > > the > > > handler if initialization is dynamic (i.e., not part of > deployment). > > > Satish > > > > > > > > > -----Original Message----- > > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > > Sent: Wednesday, January 12, 2005 1:41 PM > > > To: Francisco Curbera > > > Cc: wsbpel-spec-edit@lists.oasis-open.org; > wsbpel@lists.oasis-open.org > > > Subject: [wsbpel] Re: [wsbpel-spec-edit] Editing team issue - > > > EventHandler und Concurrency? > > > > > > This is issue 139. In fact, the proposed language is probably 80% > of > > the > > > > > > resolution to issue 139. > > > > > > The proposed text would need to be a little more clear about how > the > > > partnerLink is copied though. For example, if a partnerLink has a > > value > > > for partnerRole when the event handler is created does the copy of > the > > > partnerLink in an event handler instance inherit that partnerRole > > value? > > > > > > Yaron > > > > > > Francisco Curbera wrote: > > > > Dieter raised the following problem with the text of Section > > 13.5.7: > > > > > > > > *-- > > > > > > > > It seems that there are conflicting statements in WS-BPEL spec > > section > > > > 13.5.7. "Concurrency Considerations" (for event handlers). > > > > > > > > Consider an event handler with a request-response operation. The > > > > "constraint that there can be at most one outstanding > synchronous > > > request > > > > on a given partner link at a given port type and operation" > implies > > > that a > > > > second request has to be rejected with a standard fault > > > > "conflictingRequest" as long as a first request is being > processed. > > > > > > > > This does not fit to the other statement "individual onEvent > event > > > handlers > > > > are permitted to have several simultaneously active instances". > > > > > > > > *-- > > > > > > > > After a short mail discussion between Dieter, Satish and myself > we > > > agreed > > > > that this looked like a text clarification more than a real > issue, > > and > > > that > > > > it would be better for the editor's team to handle is. The > proposed > > > change > > > > would affect the second paragraph in Section 13.5.7 would be as > > shown > > > > below. If nobody objects (please speak up!) I would like to have > > this > > > > directly handled by the editor's team. > > > > > > > > -> Change from: > > > > > > > > Note that, unlike onAlarm event handlers, individual onEvent > event > > > handlers > > > > are permitted to have several simultaneously active instances. > A > > > private > > > > copy of all process data and control behavior defined within an > > event > > > > handler is provided to each instance of an event handler. This > > > includes > > > > the behavior of links defined within an event handler. Each > > instance > > > of > > > > the event handler must independently evaluate the status of the > > link > > > as > > > > needed. > > > > > > > > -> To: > > > > > > > > Note that, unlike onAlarm event handlers, individual onEvent > event > > > handlers > > > > are permitted to have several simultaneously active instances. > The > > > presence > > > > of multiple simultaneous active instances of the same event > handler > > is > > > not > > > > considered to violate the constraint regarding outstanding > > synchronous > > > > requests stated before, because each instance of the event > handler > > is > > > > executed within its own private environment. A private copy of > all > > > process > > > > data and control behavior defined within an event handler is > > provided > > > to > > > > each instance of an event handler. This includes all variables, > > > > correlation sets and partnerLinks declared in scopes local to an > > event > > > > handler as well as the behavior of links defined and used within > an > > > event > > > > handler. Each instance of the event handler must independently > > > evaluate > > > > the status of links local to the handler as needed. Note that > > links > > > are > > > > not permitted to cross an event handler boundary (see Section > > 12.5). > > > > > > > > > > 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/leave_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/leave_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/leave_workgr > oup.php > . > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]