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

["Satish Thatte" <satisht@microsoft.com>]

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.