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

Reply via email to