This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 86259 - Static check for bpel:conflictingReceive: multiple parallel for-each
Summary: Static check for bpel:conflictingReceive: multiple parallel for-each
Status: RESOLVED FIXED
Alias: None
Product: soa
Classification: Unclassified
Component: BPEL Validation (show other bugs)
Version: 5.x
Hardware: All All
: P4 blocker (vote)
Assignee: Vladimir Yaroslavskiy
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-01 01:42 UTC by kiran_bhumana
Modified: 2008-08-12 15:58 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
validation explanantion (10.96 KB, application/octet-stream)
2007-02-08 20:50 UTC, kiran_bhumana
Details
Test project (9.69 KB, application/x-compressed)
2008-08-12 15:58 UTC, Vladimir Yaroslavskiy
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kiran_bhumana 2006-10-01 01:42:44 UTC
If the static evluation results in a possibility of multiple parallel for-each
executions, then editor should throw an exception. Please see the email exchanges.

========
The best way to reason about parallel for-each is to transform it into an
equivalent <flow> construct. In general, if the <receive>s use the same
partnerLink, operation, and correlationSet(s), and they are concurrently active,
a bpel:conflictingReceive must be thrown. You'd really have to work at it to
avoid such an outcome in a parallel for-each with a <receive> inside.

-Ron

Kiran Bhumana wrote: 
Ron / Monica,
 
If a BPEL for each defines a “Receive” and has ‘parallel=”yes” ‘ wouldn’t that
cause a conflictingReceive fault?
===========
Comment 1 kiran_bhumana 2006-10-01 01:45:12 UTC
I meant, a validation "error" should be thrown when a receive is available in
the for-each.
Comment 2 Michael Frisino 2006-10-01 08:57:43 UTC
Need to check if this this one of the static analysis rules defined by the BPEL
specification. Or if this is  above and beyond that level of analysis.

Not sure if you know, but,  parallel=yes  is not supported for ForEach in this
release.
Comment 3 kiran_bhumana 2006-10-02 06:01:43 UTC
This is beyond the current static validations defined in the spec.
Yes, i am aware that we are not supporting the parallel FOREACH.
Comment 4 Michael Frisino 2006-10-02 08:59:52 UTC
I don't see this as being urgent for this rlease since the parallel=”yes” is not
even supported by runtime. So there is certainly no need to push for
integrtation of such fix before release.
Comment 5 Denis Anisimov 2006-10-02 10:42:12 UTC
Since there is no such rule in static analysis set of rules ( common static
analiysis rules published by OMG ) I marked this is as enhancement.

We have many rules from static analysis that is not yet implemented.
All of them are enhancments.
They needs to be implemented in next release.

And one more. I don't understand EXACT situation when static analysis rule should
detect error.
I need exact and detailed description of this rule.
Comment 6 kiran_bhumana 2007-02-08 20:50:28 UTC
Created attachment 38261 [details]
validation explanantion
Comment 7 kiran_bhumana 2007-02-08 21:05:44 UTC
accidentally created the attachment 90323 [details]-propAliasValidation.odt, it is for bug
90323. I can't delete the attachment once it is attached. Please ignore this
attachment.
Comment 8 Vladimir Yaroslavskiy 2007-04-03 12:48:36 UTC
engine doesn't have parallel foreach
Comment 9 Vladimir Yaroslavskiy 2008-05-23 15:12:19 UTC
What will be implemented:

if for-each has "parallel"=yes and <receive>s use the same partnerLink, operation, and correlationSet(s), error will be
shown.
Comment 10 Vladimir Yaroslavskiy 2008-08-12 15:57:52 UTC
fixed in soa-dev: 26418f3aa4e8
Comment 11 Vladimir Yaroslavskiy 2008-08-12 15:58:31 UTC
Created attachment 67150 [details]
Test project