Hi,
I've been disconnected from the network for the last two days. Sorry
for jumping in late.
I don't like the idea of using threadLocals for this because it creates
undesirable thread affinities. More complex scenarios involving
intervening async calls will result in the need to propagate this context to
other threads. See my previous post. I really rather go that way,
esp. since I think that is the spec group's intention.
Dave
----- Original Message -----
From: "Simon Nash" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Saturday, July 21, 2007 7:07 PM
Subject: Re: Conversational - spec question
Sorry for the delay in responding. I have been very preoccupied with
debugging the new Web Service callback implementation. I believe there
is good news on this - see below.
Simon
ant elder wrote:
On 7/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
ant elder wrote:
> 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 think my callback implementation handles this correctly. The injected
callback does not hold the callback destination statefully (giving the
side benefit that this injection could be optimized to only happen once).
When the request arrives on the server thread, the return addressing
information is placed in the thread-local message context (the code
handles
both remote and local callbacks). When the injected callback is invoked,
it uses the information in the thread-local message context to determine
where the callback should be routed.
>> 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]
>
>
Yes, we could throw an exception at assembly/startup time, or even
simpler... I'm not sure we need to write any code to handle this at this
point, we could just make clear here on the list that some
configurations are not supported and that the behavior is undefined
until clarified with the spec for:
- injection of thread-specific information (requestContext, callback)
into component instances shared across threads (scopes other than
stateless).
- injection of conversation-specific information (conversationID,
conversationAttributes) into component instances shared across
conversations (scopes other than conversational and stateless)
Thoughts?
Sounds good to me. I shall go write no code for it :)
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
