New Issue - Link Semantics in Event Handlers

["Yuzo Fujishima" <fujishima@bc.jp.nec.com>]

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
>