[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]