[
https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652136#action_12652136
]
Assaf Arkin commented on ODE-262:
---------------------------------
"In reality, if we end up with more than one instance with the same correlation
key values and if what instance receives any successive non-instance creating
messages is non-deterministic, the outcome of processing of such messages
becomes non-deterministic. Therefore, supporting non-uniqueness does not do
anything."
In reverse, what you guarantee is that only one instance will exist, up until
that instance terminates, and then you can start another one. So now that
"guarantee" depend on timing and probability and what happens to the instance.
The current implementation has very simple semantics. If you send two
messages, two messages will be processed. It's a much as you can learn from
the service interface, which works very well in an SOA because you're striving
for loose coupling: designing services and their clients around the shared
interface.
Designing the client around what the process instance will do based on what the
process definition (implementation does) is tight coupling, I don't see how
that makes the engine better.
> Duplicated correlation set values is accepted and creates a second instance
> instead of throwing an exception
> ------------------------------------------------------------------------------------------------------------
>
> Key: ODE-262
> URL: https://issues.apache.org/jira/browse/ODE-262
> Project: ODE
> Issue Type: Bug
> Components: BPEL Runtime
> Affects Versions: 1.1.1
> Environment: Apache ODE 1.1.1 or 1.2
> Tomcat
> The counter example of infoq.
> Reporter: Amin Anjomshoaa
> Assignee: Karthick Sankarachary
> Fix For: 2.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The classical counter example of infoq
> (http://www.infoq.com/articles/paul-brown-ode) can be used. Sending the
> "init" message for the second (third, fourth, ... ) time with the value "foo"
> will create a new instance. I was expecting a CorrelationViolation exception
> when the second init message is arriving.
> All upcoming messages are then correlated with the last instance only.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.