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:]
>>> Sent: Wednesday, January 12, 2005 1:41 PM
>>> To: Francisco Curbera
>>> Cc: ;
>>> 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.
>>>
>>
>
