You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by "Amin Anjomshoaa (JIRA)" <ji...@apache.org> on 2008/04/07 19:11:25 UTC
[jira] Created: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
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.2
Environment: Apache ODE 1.1.1 or 1.2
Tomcat
The counter example of infoq.
Reporter: Amin Anjomshoaa
Fix For: 1.2
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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Sean Ahn (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "deBugger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595667#action_12595667 ]
deBugger commented on ODE-262:
------------------------------
Also looking at this demo, I found that issuing "get" request to non existing counter produces timeout, instead of "Correlation-Not-Exist" exception.
> 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
> 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.
[jira] Updated: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Matthieu Riou (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthieu Riou updated ODE-262:
------------------------------
Fix Version/s: 1.3
> 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
> Fix For: 1.3
>
> 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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658206#action_12658206 ]
Alex Boisvert commented on ODE-262:
-----------------------------------
I am concerned about the name change from CorrelationKeySet to CorrelationKeys since this class is serializable and is in fact serialized in the CorrelationNoMatchEvent as well as Selector. The Selector class is actually serialized as part of the Jacob state which does not use Java serialization.
I think it may be wise to revert the commit and review the code further until we have fully reviewed and tested to some extent, the backward compatibility aspects.
> 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
>
> Attachments: unique-correlation-set-for-branch.patch
>
> 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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651224#action_12651224 ]
Karthick Sankarachary commented on ODE-262:
-------------------------------------------
As of now, processes behave as if the value of our hypothetical "unique" attribute is "false". Yes, our default behavior may cause intermediate messages to be routed non-deterministic. However, I think we should support it for the sake of backward-compatibility, if nothing else.
> 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.
[jira] Updated: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-262:
--------------------------------------
Attachment: unique-correlation-set-for-branch.patch
The attached patch implements the "unique" attribute extension on the <correlationSet> element as shown below:
<correlationSet name="name" properties="p1 p2 ..." unique="yes|no">
To illustate its use, we apply this attribute to the classical counter example described above. In order to keep duplicate "init" messages from instantiating multiple (process) instances, you will need to constrain the correlation set defined on that message type to be "unique", like so:
<b:correlationSets>
- <b:correlationSet name="name" properties="t:counterProp"/>
+ <b:correlationSet name="name" properties="t:counterProp" unique="yes"/>
</b:correlationSets>
Consequently, every time that correlation set is initialized in a start activity, the server will check to see if there are any instances running with that correlation value. If such an instance does exist, then the server responds with an appropriate SOAP fault message. If, and only if, no such instance is found, does the server create a new instance.
By way of an example, the first time you send an "init" message with the name "foo", as shown below, the server will start a new instance with that name.
<soapenv:Body>
<coun:init>
<name>foo</name>
</coun:init>
</soapenv:Body>
The second time you send an "init" message with the same name ("foo"), you will get a fault message back, as shown below:
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server</faultcode>
<faultstring xmlns:axis2ns1="http://www.apache.org/ode/type/extension">axis2ns1:duplicateInstance</faultstring>
<detail>
<fault xmlns="http://www.apache.org/ode/type/extension">Found a duplicate instance with the same message key</fault>
</detail>
</soapenv:Fault>
</soapenv:Body>
On the other hand, if you send an "init" message with a different name (say "bar"), as shown below, then the server will go ahead and start another instance with the new name.
<soapenv:Body>
<coun:init>
<name>bar</name>
</coun:init>
</soapenv:Body>
Note that care was taken to deal with race conditions caused by duplicate messages that arrive at the exact same instant. As for the proposed extension to make correlation sets durable, that has been deferred for now, in part because it involves a performance penalty.
> 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
>
> Attachments: unique-correlation-set-for-branch.patch
>
> 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.
[jira] Updated: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-262:
--------------------------------------
Attachment: (was: unique-correlation-set-for-trunk.patch)
> 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
>
> Attachments: unique-correlation-set-for-branch.patch
>
> 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.
[jira] Issue Comment Edited: (ODE-262) Duplicated correlation set
values is accepted and creates a second instance instead of throwing an
exception
Posted by "Sean Ahn (JIRA)" <ji...@apache.org>.
[ 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 1:15 PM:
-------------------------------------------------------
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 <receive>s but to any activities that can initiate a correlation during the execution of the instance: <receive>, <reply>, <onMessage>, <onEvent>, and <invoke>.
4. If some of the databases that we support do 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 contain 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 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 do 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 contain 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.
[jira] Updated: (ODE-262) Treating Duplicate Correlation Set Values
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-262:
--------------------------------------
Summary: Treating Duplicate Correlation Set Values (was: Duplicated correlation set values is accepted and creates a second instance instead of throwing an exception)
> Treating Duplicate Correlation Set Values
> -----------------------------------------
>
> 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
>
> Attachments: unique-correlation-set-for-branch.patch, unique-correlation-set-for-trunk.patch, unique-correlation-set-non-instantiating.patch
>
> 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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Assaf Arkin (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-262:
--------------------------------------
Attachment: unique-correlation-set-non-instantiating.patch
On second thought, the constraint of uniqueness of correlation sets should be enforced on not only instantiating receives, but also intermediate receives and for that matter, any inbound or outbound message activity in which a correlation set may potentially be initialized, such as a <reply>, <invoke>, <pick> or <onEvent> activity.
The patch that goes with this comment accomplishes just that.
> 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
>
> Attachments: unique-correlation-set-for-branch.patch, unique-correlation-set-for-trunk.patch, unique-correlation-set-non-instantiating.patch
>
> 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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650760#action_12650760 ]
Karthick Sankarachary commented on ODE-262:
-------------------------------------------
There's no language in the BPEL spec that explicitly prohibits the initiation of multiple instances of a process through duplicate messages. In fact, all of the standard BPEL faults that relate to inbound message activities (IMAs), including the <receive> activity, are thrown in the context of a process instance that's already instantiated. Hence, if you were to send the "init" message below two or more times, you will end with two or more instances of the process, despite the fact that they all carry the same name (i.e., "foo") .
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/" xmlns:counter="http://example.com/bpel/counter">
<Header/>
<Body>
<counter:init>
<name>foo</name>
</counter:init>
</Body>
</Envelope>
An "upcoming messages" that is targeted at a non-initiating receive will be correlated against a running instance. The decision as to which receive the message is targeted at is made based, in part, on the operation name it contains. For example, the message below will be sent to the "get" <receive> activity, which is non-initiating, and hence correlatable:
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/" xmlns:counter="http://example.com/bpel/counter">
<Header/>
<Body>
<counter:get>
<name>foo</name>
</counter:get>
</Body>
</Envelope>
Having said that, it would be nice to be able to say that, at any given point in time, the correlation is unique across all instances of the process. To that end, how about if we add an extension attribute (called "unique" below) in the correlation of the initiating receive?
<correlations>
<correlation set="name" initiate="yes" unique="yes"/>
</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.
[jira] Issue Comment Edited: (ODE-262) Duplicated correlation set
values is accepted and creates a second instance instead of throwing an
exception
Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658206#action_12658206 ]
boisvert edited comment on ODE-262 at 12/19/08 2:23 PM:
-------------------------------------------------------------
I am concerned about the name change from CorrelationKeySet to CorrelationKeys since this class is serializable and is in fact serialized in the CorrelationNoMatchEvent as well as Selector. The Selector class is actually serialized as part of the Jacob state which does not use standard Java serialization (it "compresses" the state and discard some of the serialization headers)
I think it may be wise to revert the commit and review the code further until we have fully reviewed and tested to some extent, the backward compatibility aspects.
was (Author: boisvert):
I am concerned about the name change from CorrelationKeySet to CorrelationKeys since this class is serializable and is in fact serialized in the CorrelationNoMatchEvent as well as Selector. The Selector class is actually serialized as part of the Jacob state which does not use Java serialization.
I think it may be wise to revert the commit and review the code further until we have fully reviewed and tested to some extent, the backward compatibility aspects.
> 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
>
> Attachments: unique-correlation-set-for-branch.patch
>
> 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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658197#action_12658197 ]
Karthick Sankarachary commented on ODE-262:
-------------------------------------------
The changes are indeed backward-compatible. In general, you want to avoid changing the signature of existing methods in the process model. On the other hand, it is okay to add new fields or methods in the model, which as a matter of fact, I did do in this particular case.
> 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
>
> Attachments: unique-correlation-set-for-branch.patch
>
> 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.
[jira] Assigned: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex Boisvert reassigned ODE-262:
---------------------------------
Assignee: Karthick Sankarachary
> 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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650825#action_12650825 ]
Alex Boisvert commented on ODE-262:
-----------------------------------
I think adding the unique attribute makes sense.
> 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.
[jira] Issue Comment Edited: (ODE-262) Duplicated correlation set
values is accepted and creates a second instance instead of throwing an
exception
Posted by "Sean Ahn (JIRA)" <ji...@apache.org>.
[ 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 1:08 PM:
-------------------------------------------------------
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 do 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 contain 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 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.
> 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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Matthieu Riou (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651248#action_12651248 ]
Matthieu Riou commented on ODE-262:
-----------------------------------
A couple issues I can see:
1. There are a few corner cases where we'll deny valid messages. Hopefully it won't be too common.
2. I'm not sure we can implement this without pretty much serializing new instance creation, to avoid race conditions. We can try to commit asap and rely on the route lock for non-instantiating but the throughput is still going to be impacted.
For more on 1. consider the following case where correlations are declared unique:
sequence {
...
receive(pl, op, foo initiate=true, baz initiate=false); // foo is the correlation
...
receive(pl, op, bar initiate=true, baz initiate=false); // same partner link and operation, different correlation
...
}
When we receive a message, we only have the partner link and the operation. So to route we have to use all correlations on this pl/op tuple. Therefore on the first receive, we'll also have to check the bar correlation. If the message happens to contain an element that matches bar with a non unique value, we'll have to reject it. Even though it could be, strictly speaking, valid.
> 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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Matthieu Riou (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651266#action_12651266 ]
Matthieu Riou commented on ODE-262:
-----------------------------------
One more thing, why:
<correlations>
<correlation set="name" initiate="yes" unique="yes"/>
</correlations>
It's going to be horribly confusing to enforce correlation unicity only sometimes. It should be declared on the correlation set definition and enforced throughout the process.
> 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.
[jira] Resolved: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary resolved ODE-262.
---------------------------------------
Resolution: Fixed
The patch has been ported to trunk. On a side note, the change in the class name cited in the previous note is here to stay.
> 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
>
> Attachments: unique-correlation-set-for-branch.patch, unique-correlation-set-for-trunk.patch
>
> 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.
[jira] Updated: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Amin Anjomshoaa (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Amin Anjomshoaa updated ODE-262:
--------------------------------
Fix Version/s: (was: 1.2)
Affects Version/s: (was: 1.2)
1.1.1
> 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
> 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.
[jira] Issue Comment Edited: (ODE-262) Duplicated correlation set
values is accepted and creates a second instance instead of throwing an
exception
Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658190#action_12658190 ]
boisvert edited comment on ODE-262 at 12/19/08 1:39 PM:
-------------------------------------------------------------
Karthick, does this change in any way the persistence of process definitions, instances or any other persistent object in Ode? (I can't easily tell from the commit because of the changes in line-ending characters). And if so, are the changes backward-compatible?
was (Author: boisvert):
Karthick, does this change in any way the persistence of process definitions, instances or any other persistent object in Ode? (I can't easily tell from the commit because of the changes in line-ending characters)
> 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
>
> Attachments: unique-correlation-set-for-branch.patch
>
> 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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652113#action_12652113 ]
Karthick Sankarachary commented on ODE-262:
-------------------------------------------
To answer Matthieu's comment, yes, the "unique" attribute is better off being declared in the correlation set definition, especially since a correlation set can never ever be initialized more than once. Furthermore, it would be nice to have a "durable" attribute in the correlation set declaration that says whether or not the correlation set has to be unique across all instances, both active and completed. To recapitulate, the revised extensions are as shown below:
<correlationSet name="name" properties="bar foo ..." unique="yes|no" durable="yes|no"/>
> 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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651730#action_12651730 ]
Alex Boisvert commented on ODE-262:
-----------------------------------
One use-case where we need to allow duplicate correlations is for pub-sub -- so it's not just about backward-compatibility.
> 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.
[jira] Updated: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-262:
--------------------------------------
Attachment: unique-correlation-set-for-trunk.patch
> 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
>
> Attachments: unique-correlation-set-for-branch.patch, unique-correlation-set-for-trunk.patch
>
> 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.
[jira] Updated: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Matthieu Riou (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthieu Riou updated ODE-262:
------------------------------
Fix Version/s: (was: 1.3)
2.0
> 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
> 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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Matthieu Riou (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651240#action_12651240 ]
Matthieu Riou commented on ODE-262:
-----------------------------------
I've also heard fairly valid arguments pointing out that unique="true" is just as much non-deterministic :)
By the way a couple of implementation notes:
* For an instantiating receive, a new instance shouldn't be created if it violates unicity.
* For a non-instantiating receive (but initiating of course), the instance shouldn't get loaded.
Probably sounds obvious but just wanted to make it clear as it's not the easiest implementation path.
> 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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658214#action_12658214 ]
Karthick Sankarachary commented on ODE-262:
-------------------------------------------
Would you like me to rename CorrelationKeys back to CorrelationKeySet? The reason I changed the name of that class in the first place is because it represents a message activity's <correlations> element, as opposed to its <correlation set="..."> element. While the name "CorrelationKeySet" maybe a misnomer, I don't mind going back to it, for the sake of backwards compatibility.
> 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
>
> Attachments: unique-correlation-set-for-branch.patch
>
> 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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658190#action_12658190 ]
Alex Boisvert commented on ODE-262:
-----------------------------------
Karthick, does this change in any way the persistence of process definitions, instances or any other persistent object in Ode? (I can't easily tell from the commit because of the changes in line-ending characters)
> 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
>
> Attachments: unique-correlation-set-for-branch.patch
>
> 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.
[jira] Commented: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Sean Ahn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651221#action_12651221 ]
Sean Ahn commented on ODE-262:
------------------------------
I'm not sure if we want to support unique="false" at all if we're going to invest to this issue.
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.
> 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.
[jira] Issue Comment Edited: (ODE-262) Duplicated correlation set
values is accepted and creates a second instance instead of throwing an
exception
Posted by "Sean Ahn (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (ODE-262) Duplicated correlation set values is
accepted and creates a second instance instead of throwing an exception
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-262:
--------------------------------------
Attachment: unique-correlation-set-for-trunk.patch
The availability of the feature described herein has been limited to the latest (v2) version of the process model in the trunk. For some reason unbeknownst to me, this feature introduces an incompatibility error in the earlier (v1) version of the process model, and for that reason has been disabled therein.
> 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
>
> Attachments: unique-correlation-set-for-branch.patch, unique-correlation-set-for-trunk.patch
>
> 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.