Singleton of instances in BPEL Correlations

[Amin Anjomshoaa <an...@ifs.tuwien.ac.at>]

Hi

In the counter classical example of ODE, after each "init" request with 
the same variable name (foo for example), a new instance is generated 
and next messages (get, getAndIncrement, etc) are always correlated with 
the last instance only. Is there a way to drop an exception for the 
second "init" with the same variable name?

Thanks
Amin

Re: Re: Singleton of instances in BPEL Correlations

[Amin Anjomshoaa <an...@ifs.tuwien.ac.at>]

Hi Paul

Thanks for your replay. Yes, I mean the example of InfoQ article. I 
guess the idea of adding a thread will not work, because the init will 
be replied by the first receive and as I explained previously this 
creates a new instance with the same variable name (the same correlation 
value). I have filed a bug for this issue Jira and hope to get results soon.

Regards
Amin

Paul Brown wrote:
> <div class="moz-text-flowed" style="font-family: -moz-fixed">
> Hi, Amin --
>
>> In the counter classical example of ODE, after each "init" request 
>> with the same variable name (foo for example), a new instance is 
>> generated and next messages (get, getAndIncrement, etc) are always 
>> correlated with the last instance only. Is there a way to drop an 
>> exception for the second "init" with the same variable name?
>
>
> I'm going to assume that you're talking about the process that's in 
> the InfoQ article about ODE.
>
> Are you thinking of how to respond with a fault if someone attempts to 
> initialize an already initialized key?  To do that, you could add an 
> additional "thread" to the flow activity that would get "init" 
> messages for an already in-progress instance.
>
> As for what happens if that's not the case, I'm going to have to think 
> about it or try an example to remember...
>
> Best.
>
> Paul Brown
> paulrbrown@gmail.com
>
>
>
> </div>

Re: Singleton of instances in BPEL Correlations

[Paul Brown <pa...@gmail.com>]

Hi, Amin --

> In the counter classical example of ODE, after each "init" request  
> with the same variable name (foo for example), a new instance is  
> generated and next messages (get, getAndIncrement, etc) are always  
> correlated with the last instance only. Is there a way to drop an  
> exception for the second "init" with the same variable name?


I'm going to assume that you're talking about the process that's in  
the InfoQ article about ODE.

Are you thinking of how to respond with a fault if someone attempts to  
initialize an already initialized key?  To do that, you could add an  
additional "thread" to the flow activity that would get "init"  
messages for an already in-progress instance.

As for what happens if that's not the case, I'm going to have to think  
about it or try an example to remember...

Best.

Paul Brown
paulrbrown@gmail.com

Re: Re: Singleton of instances in BPEL Correlations

[Amin Anjomshoaa <an...@ifs.tuwien.ac.at>]

Hi Alex

Thanks for the quick reply. Yes, I meant correlation set values. At the 
first initialization activity the duplicated values are accepted and 
create new instances. I have submitted a bug for this issue : 
https://issues.apache.org/jira/browse/ODE-262

Regards
Amin

Alex Boisvert wrote:
> On Sun, Apr 6, 2008 at 7:09 AM, Amin Anjomshoaa <an...@ifs.tuwien.ac.at>
> wrote:
>
>   
>> In the counter classical example of ODE, after each "init" request with
>> the same variable name (foo for example), a new instance is generated and
>> next messages (get, getAndIncrement, etc) are always correlated with the
>> last instance only. Is there a way to drop an exception for the second
>> "init" with the same variable name?
>>     
>
>
> You mean the same correlation-set value(s)?    I think that should be the
> default behavior but apparently it's not.  Can you file a bug?
>
> alex
>
>   

Re: Singleton of instances in BPEL Correlations

[Alex Boisvert <bo...@intalio.com>]

On Sun, Apr 6, 2008 at 7:09 AM, Amin Anjomshoaa <an...@ifs.tuwien.ac.at>
wrote:

> In the counter classical example of ODE, after each "init" request with
> the same variable name (foo for example), a new instance is generated and
> next messages (get, getAndIncrement, etc) are always correlated with the
> last instance only. Is there a way to drop an exception for the second
> "init" with the same variable name?


You mean the same correlation-set value(s)?    I think that should be the
default behavior but apparently it's not.  Can you file a bug?

alex