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

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

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