[
https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652130#action_12652130
]
Sean Ahn commented on ODE-262:
------------------------------
We need to create a new table, UNIQUE_CORRELATION_SET(ID, CORRELATION_VALUE,
IS_DURABLE).
One row per a correlation set value is created in the table and the
CORRELATION_VALUE contains a combined string of PROCESS_ID, CORRELATION_NAME
and the value of the correlation set. The CORRELATION_VALUE column is indexed
uniquely.
1. For an instance creating incoming message, as many new rows as the number of
unique correlation sets that are defined in the message are inserted to the
table.
2. The process continues the normal processing with persisting the correlation
sets and properties and completes to the end.
3. When the process completes, depending on the 'durable' attribute, the rows
are deleted from the table or remain.
4. During the steps above, if another instantiating message that contains the
same value for a unique correlation set arrives, a database native exception
that is interpreted as a correlation violation exception is thrown and the
transaction gets aborted.
Assessment:
1. OModel will be changed but without backward compatibility problem.
2. A new table will be created.
3. This unicity validation does not only apply to instance creating receives
but to any activities that can initiate a correlation during the execution of
the instance.
e.g. invoke
4. If some of the databases that we support does not handle unique indexing
well, we might have to employ a database table lock on the new table. This lock
will serialize all activities that contains any initiating unique correlations.
> 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.
