[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] New Issue 215: Conflicting Receive in Parallel Foreach?
Hi Alex - I filed this one.. 1) There are no explicit Engine Managed Correlation Sets, now that 96 is closed, correct? 2) Implicit Engine Managed Correlation Sets would still have to be portable, and so then may not run on an engine where they do not exist, or run differently. I'm not sure how you envision 120.1 ending up, but it seems that what you're suggesting is a clarification, anyway, in which case we should probably open this as a bug pending a bit more discussion? Danny Alex Yiu wrote: > > Hi Yuzo, > > IMHO, it do not necessarily create any ConflictReceive situation, if one > uses message operation properly. Typically, it will involve a locally > scoped partnerLink PLUS a locally scoped correlation set** (A number of > cases, please see below) > > The correlation set would be initialized explicitly or implicitly by the > <invoke> (preceding the receive) > > The Correlation Set would be either: > > * Explicit: (with a construct attached to receive) > o "vanilla" correlation set > o engine managed correlation set (related to Issue 96) > * Implicit: (without an explicit construct by the correlation is > activated implicitly by deployment steps) > o typically engine managed correlation set(related to Issue 120.1) > > > Since we closed Issue 96 with no change, we would need a paragraph from > 120.1 to explain two cases of engine managed correlation sets. > > > Thanks! > > > Regards, > Alex Yiu > > > > Tony Fletcher wrote: > >> >> >> This issue has been added to the wsbpel issue list with a status of >> "received". The status will be changed to "open" if the TC accepts it >> as identifying a bug in the spec or decides it should be accepted >> specially. Otherwise it will be closed without further consideration >> (but will be marked as "Revisitable") >> >> The issues list is posted as a Technical Committee document to the >> OASIS WSBPEL TC pages >> <http://www.oasis-open.org/apps/org/workgroup/wsbpel> on a regular >> basis. The current edition, as a TC document, is the most recent >> version of the document entitled in the "Issues" folder of the WSBPEL >> TC document list >> <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> - >> the next posting as a TC document will include this issue. The list >> editor's working copy, which will normally include an issue when it is >> announced, is available at this constant URL >> <http://www.choreology.com/external/WS_BPEL_issues_list.html>. >> >> >> ------------------------------------------------------------------------ >> >> >> Issue 215: Conflicting Receive in Parallel Foreach? >> >> *Status:* received >> *Date added:* 4 Jun 2005 >> *Categories:* Partner Links >> <http://www.choreology.com/external/WS_BPEL_issues_list.html#category_partner_links> >> *Date submitted:* 03 June 2005 >> *Submitter:* Danny van der Rijn <mailto:dannyv@tibco.com> >> *Description:* >> >> A la Yuzo's issue 208 >> <http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue208>, >> we now have another case that I'm confused about. Consider the following: >> >>foreach parallel="yes" >> receive partnerlink="foo" operation="bar" >> >> This will be more likely if, say, I have an "asynchronous" operation >> with my partners: >> >>operation request >>operation reply >> >> I have N partnerlinks, 1 for each of my N partners, on which I send >> the request operation, but I only need 1 partnerlink to receive >> "reply" on. >> >> So the loop would really look like: >> >>foreach parallel="yes" >> scope >> partnerlink name="foo" >> assign from="$partnerEPRArray[$foreachIndex]" to="foo" >> invoke parterlink="foo" >> receive partnerlink="me" >> >> >> or something like that. But the part that comes into conflict is the >> simplified pseudo-code snippet above. >> >> Q1: Wouldn't that cause a conflicting receive fault? >> Q2: If not, why not? >> Q3: If so, do we solve this? >> Q4: If not, do we put text in the spec explaining the problem, and why >> we don't fix it? >> *Changes:* 4 Jun 2005 - new issue >> >> ------------------------------------------------------------------------ >> >> >> >> >> Best Regards, >> >> Tony/ / >> >> / <http://www.choreology.com/>/ >> >> >> >> Tony Fletcher >> >> Technical Advisor >> Choreology Ltd. >> 68, Lombard Street, London EC3V 9L J UK >> >> Phone: >> >> >> >> +44 (0) 1473 729537 >> >> Mobile: >> >> >> >> +44 (0) 7801 948219// >> >> Fax: >> >> >> >> +44 (0) 870 7390077 >> >> Web: >> >> >> >> /www.choreology.com <http://www.choreology.com/>/ >> >> Cohesions™ >> >> Business transaction management software for application coordination >> >> Work: tony.fletcher@choreology.com >> >> Home: amfletcher@iee.org <mailto:amfletcher@iee.org> >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]