[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?
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_workgroup.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_workgroup.php. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]