OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-spec-edit message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


My understanding is that there was no intent to address 139 (engine
managed EPRs etc).  Dieter and Paco, please confirm.

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Thursday, January 20, 2005 1:12 PM
To: Satish Thatte
Cc: Francisco Curbera; wsbpel-spec-edit@lists.oasis-open.org;
wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Re: [wsbpel-spec-edit] Editing team issue -
EventHandler und Concurrency?

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]