[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?
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. >>>> >>> >> > >
begin:vcard fn:Assaf Arkin n:Arkin;Assaf org:Intalio adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065 email;internet:arkin@intalio.com title:Chief Architect tel;work:(650) 596-1800 x-mozilla-html:TRUE url:http://www.intalio.com version:2.1 end:vcard
S/MIME Cryptographic Signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]