RE: [wsbpel] Link semantics in event handlers

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

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

-----Original Message-----
From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com] 
Sent: Monday, May 26, 2003 1:36 AM
To: wsbpel@lists.oasis-open.org
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


---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org