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

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

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