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: New Issue 215: Conflicting Receive in Parallel Foreach?


Title: Message
 
 
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 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 - 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  

 

Issue 215: Conflicting Receive in Parallel Foreach?

Status: received
Date added: 4 Jun 2005
Categories: Partner Links
Date submitted: 03 June 2005
Submitter: Danny van der Rijn
Description:

A la Yuzo's issue 208, 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                          

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

Cohesions™

Business transaction management software for application coordination

Work: tony.fletcher@choreology.com

Home: amfletcher@iee.org

 


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