[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?
Exactly. Thanks Paco. I meant to reply but it slipped through the
many cracks.
-----Original Message-----
From: Francisco Curbera [mailto:curbera@us.ibm.com]
Sent: Monday, January 24, 2005 10:37 PM
To: ygoland@bea.com
Cc: Dieter Koenig1; Satish Thatte; wsbpel@lists.oasis-open.org;
wsbpel-spec-edit@lists.oasis-open.org
Subject: Re: [wsbpel] Re: [wsbpel-spec-edit] Editing team issue -
EventHandler und Concurrency?
I think Satish was referring to engine managed EPRs, not correlations.
As I
understand 139 it is about how the engine will manage the binding of
partner links. This is somewhat related but different and much more
generic
than the problem Dieter raised: the possible violation of the "at most
one"
outstanding request constraint by concurrently executing event handlers.
Paco
"Yaron Y. Goland"
<ygoland@bea.com> To: Dieter Koenig1
<dieterkoenig@de.ibm.com>
cc: Satish Thatte
<satisht@microsoft.com>, Francisco Curbera/Watson/IBM@IBMUS,
01/21/2005 06:48
wsbpel@lists.oasis-open.org, wsbpel-spec-edit@lists.oasis-open.org
PM Subject: Re: [wsbpel]
Re: [wsbpel-spec-edit] Editing team issue - EventHandler und
Concurrency?
Please respond to
ygoland
Huh? Where did engine managed correlations come from? Please review my
letter on 1/20/2005 included below. It states, I thought, quite clearly
exactly what issue I thought you may be addressing and explains why I
object to the currently proposed language. No where in there did I mean
to address or even imply anything about engine managed correlations.
Now I'm just confused,
Yaron
Dieter Koenig1 wrote:
>
>
>
> This is correct, it was not meant to be linked to 139.
> Kind Regards
> DK
>
>
>
>
> "Satish Thatte"
> <satisht@microsof
> t.com>
To
> <ygoland@bea.com>
> 20.01.2005 14:39
cc
> "Francisco Curbera"
> <curbera@us.ibm.com>,
>
<wsbpel-spec-edit@lists.oasis-open.
> org>,
> <wsbpel@lists.oasis-open.org>,
> Dieter
Koenig1/Germany/IBM@IBMDE
>
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.
> >
>
> 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
> .
>
>
>
>
> 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]