ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Ahn (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (ODE-262) Duplicated correlation set values is accepted and creates a second instance instead of throwing an exception
Date Mon, 01 Dec 2008 19:59:44 GMT

    [ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652130#action_12652130
] 

seanahn edited comment on ODE-262 at 12/1/08 11:58 AM:
--------------------------------------------------------

We need to create a new table, UNIQUE_CORRELATION_SET(ID, CORRELATION_VALUE, IS_DURABLE).

One row per a unique 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.

      was (Author: seanahn):
    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.


Mime
View raw message