[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel-spec-edit] Re: [wsbpel] Re: [wsbpel-spec-edit] Editingteam issue - EventHandler und Concurrency?
Sigh... we need an editors issues list. Satish? Yaron Assaf Arkin wrote: > Yes indeed. I was only proposing new text for the sentences that discuss > partner links (as marked), and copied the rest verbatim from the > original proposal to preserve context. I assume there's another issue to > deal with the onAlarm portion of the paragraph. > > Assaf > > Yaron Y. Goland wrote: > >> I thought we had passed a proposal allowing for repeating alarms? In >> that case it is possible to have multiple simultaneous onAlarm event >> handlers running. >> >> Yaron >> >> Assaf Arkin wrote: >> >>> How about: >>> >>> 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 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. /As a result, multiple simultaneous active >>> instances of the same event handler that use a locally declared >>> partner link in their receive activity do not violate the constraint >>> regarding outstanding synchronous requests stated before, since each >>> instance of the event handler is using a distinct partner link. /Note >>> that links are not permitted to cross an event handler boundary (see >>> Section 12.5). >>> >>> Assaf >>> >>> Yaron Y. Goland wrote: >>> >>>> 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. >>>>> >>>> >>> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]