Re: [wsbpel-spec-edit] Re: [wsbpel] Re: [wsbpel-spec-edit] Editingteam issue - EventHandler und Concurrency?

["Yaron Y. Goland" <ygoland@bea.com>]

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.
>>>
>>
>