From dev-return-4606-apmail-ode-dev-archive=ode.apache.org@ode.apache.org Mon Dec 01 19:56:44 2008 Return-Path: Delivered-To: apmail-ode-dev-archive@www.apache.org Received: (qmail 19595 invoked from network); 1 Dec 2008 19:56:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Dec 2008 19:56:44 -0000 Received: (qmail 57081 invoked by uid 500); 1 Dec 2008 19:56:55 -0000 Delivered-To: apmail-ode-dev-archive@ode.apache.org Received: (qmail 57065 invoked by uid 500); 1 Dec 2008 19:56:55 -0000 Mailing-List: contact dev-help@ode.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ode.apache.org Delivered-To: mailing list dev@ode.apache.org Received: (qmail 57054 invoked by uid 99); 1 Dec 2008 19:56:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 11:56:55 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 19:55:26 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 6C840234C2AC for ; Mon, 1 Dec 2008 11:55:44 -0800 (PST) Message-ID: <226326744.1228161344443.JavaMail.jira@brutus> Date: Mon, 1 Dec 2008 11:55:44 -0800 (PST) From: "Sean Ahn (JIRA)" To: dev@ode.apache.org Subject: [jira] Commented: (ODE-262) Duplicated correlation set values is accepted and creates a second instance instead of throwing an exception In-Reply-To: <1924708540.1207588285274.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on 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.