On 7/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
ant elder wrote:
> On 7/20/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> <snip>
>
> - I have to deal with concurrent requests in my business logic, but then
>> I'm having a hard time understanding how my business logic is going to
>> handle interlaced injection calls and business method calls in a
>> multi-threaded environment...
>
>
> Could you explain this issue a bit more, what do you mean "interlaced
> injection calls and business method calls"?
>
> ...ant
>
My component implementation looks like this:
class MyBrokenComponent {
Client callback;
@Callback
void setCallback(Client callback) {
this.callback = callback;
}
void echo(String s) {
callback.echoCallback(s);
}
2 concurrent requests enter a composite scoped component instance (a
single instance). I'm not feeling lucky today and it happens that my
fast Dual core processor just decided to schedule the execution of the
requests as follows:
Thread 1
component.setCallback(callback A corresponding to the request in Thread
1)
Thread 2
component.setCallback(callback 2 corresponding to the request in Thread
2)
Thread 1
echo("hey")
Thread 2
echo("hey")
Both callbacks will go to back A. Not good :) and by the way, do I need
to mark my setter methods synchronized???
I guess we can play similar scenarios and illustrate the same issues
with ConversationID, Callbacks, or RequestContext. How can this work at
all?
Right, which is why back here [1] the suggestion was throwing some exception
when its composite scoped. Can't we do that and just say conversations
aren't supported in this configuration?
...ant
[1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200707.mbox/[EMAIL
PROTECTED]
