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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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


Subject: RE: [wsbpel] New Issue - Link Semantics in Event Handlers


Yuzo,

Could you please provide a BPEL code fragment that would highlight this
problem? 

Edwin 

> 
> -----Original Message-----
> From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com] 
> Sent: Tuesday, July 01, 2003 7:50 PM
> To: wsbpel@lists.oasis-open.org
> 
> Hi,
> 
> I would like to post a new issue.
> 
> I first tried to send this to 
> wsbpel-reqts@lists.oasis-open.org but failed:
>     <wsbpel-reqts@lists.oasis-open.org>:
>     Sorry, only contributing members may post. If you are a 
> contributing member,
>     please forward this message to 
> administration@lists.oasis-open.org to get
>     your new address included (#5.7.2)
> 
> Yuzo
> 
> ----
> 
> Categories:
> 
> Document: BPEL 1.1 Specification
> 
> Short Description:
> According to 13.5.4.2 Message Events, BPEL 1.1 allows one 
> event handler activity to run concurrently. However, it is 
> not specified whether all concurrent "threads" share link 
> status or each thread maintains its own link status. Suppose 
> activity B has synchronization dependency on A. Can B in a 
> thread be run after A is completed in other thread? Or only 
> after A is completed in the same thread?
> 
> Champion:
> 
> Use Cases:
> 
> Links:
> 
> Discussion:
> 
> The following 2 messages.
> 
> ----- Original Message -----
> From: "Yuzo Fujishima" <fujishima@bc.jp.nec.com>
> To: <wsbpel@lists.oasis-open.org>
> Sent: Monday, May 26, 2003 5:36 PM
> Subject: [wsbpel] Link semantics in event handlers
> 
> 
> > Hi,
> > 
> > According to 13.5.4.2 Message Events,
> > BPEL 1.1 allows one event handler
> > activity to run concurrently. This happens when multiple
> > event messages of a type are received in short invervals.
> > 
> > Suppose there is an event handler that is a <flow> containing
> > activities A, B, and C where C has synchronization dependencies
> > on A and B. 
> > 
> > A--->C<---B
> > 
> > Suppose this <flow> is started twice in a short interval and run
> > concurrently. Let's denote the two executions as "thread-1" and
> > "thread-2". Further suppose A completes in thread-1 and B
> > completes in thread-2.
> > 
> > Can C be started then, in both thread-1 and thread-2?
> > 
> > Or should C in thread-x wait until both A and B are completed in
> > thread-x? (I think this more natural.)
> > 
> > Anyway, concurrency will complicate the semantics and
> > implementation pretty much. Allowing concurrency for the 
> > price of complicacy may make sense in some situaions but may not in
> > others. My basic preference is to simplicity, but I'm not sure
> > yet for this specific case. Do you think the concurrency
> > essential?
> > 
> > Sincerely,
> > Yuzo Fujishima
> > NEC Corporation
> 
> ----- Original Message ----- 
> From: "Satish Thatte" <satisht@microsoft.com>
> To: "Yuzo Fujishima" <fujishima@bc.jp.nec.com>; 
> <wsbpel@lists.oasis-open.org>
> Sent: Tuesday, May 27, 2003 2:29 AM
> Subject: RE: [wsbpel] Link semantics in event handlers
> 
> > 
> > Yuzo,
> > 
> > Very good question.  My interpretation of the semantics is 
> that the flow
> > in each "thread" is independent, the one you called "natural."  This
> > sort of example brings out the importance of a relatively formal
> > operational semantics for BPEL which I believe should be one of the
> > outputs of this TC.
> > 
> > As for whether the concurrency between multiple incarnations of a
> > specific event handler is needed, I am sure reasonable people can
> > disagree.  My own belief is that in many if not most use 
> cases, event
> > handlers will guard against interference in shared data 
> (with the scope
> > and with each other) by enclosing some or most of their 
> activities in
> > serializable scopes, thus naturally serializing 
> (interfering) activities
> > including multiple instances.  When this is not the case 
> (for instance
> > synchronous status query handlers that operate in read-only 
> mode against
> > infrequently updated shared data) the concurrency simply reduces the
> > need for locking and helps performance and throughput.
> > 
> > My 2 pennies.
> > 
> > Satish
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> 
> 



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