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

[Assaf Arkin <arkin@intalio.com>]

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