You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/07/20 00:40:12 UTC
Conversational - spec question
Can anyone familiar with the conversation aspects of the spec tell me what
is the specified way to get a conversationId in a stateless service, i.e a
service which implements an @Conversational interface but is not annotated
with
@Scope("CONVERSATION").
1 Spec (1.2.5.1 of JavaComponentImplementation) says that classes that
are CONVERSATION scoped may use @ConversationID. Doesn't say that those that
aren't conversation scoped can't
2 Ability to get component context implies
componentContext.getRequestContext().getServiceReference().getConversation().getConversationId().
Could we get conversationId added to the request context?
I prefer 1. 2 isn't obviously what you would want to be faced with unless we
can add more info to request context (although this way is useful if you
want to pass a reference to this conversation on to others) .
Regards
Simon
Re: Conversational - spec question
Posted by scabooz <sc...@gmail.com>.
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" <na...@hursley.ibm.com>
To: <tu...@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 <js...@apache.org> wrote:
>>
>>>
>>> ant elder wrote:
>>> > On 7/21/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>> >>
>>> >> ant elder wrote:
>>> >> > On 7/20/07, Jean-Sebastien Delfino <js...@apache.org> 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/%3c71e1b5740707200331x64d4f6e0tde2a6ae8b0d4d10d@mail.gmail.com%3e
>>> >
>>> >
>>>
>>> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Conversational - spec question
Posted by Simon Nash <na...@hursley.ibm.com>.
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 <js...@apache.org> wrote:
>
>>
>> ant elder wrote:
>> > On 7/21/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> >>
>> >> ant elder wrote:
>> >> > On 7/20/07, Jean-Sebastien Delfino <js...@apache.org> 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/%3c71e1b5740707200331x64d4f6e0tde2a6ae8b0d4d10d@mail.gmail.com%3e
>>
>> >
>> >
>>
>> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Conversational - spec question
Posted by ant elder <an...@apache.org>.
On 7/21/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > On 7/21/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >>
> >> ant elder wrote:
> >> > On 7/20/07, Jean-Sebastien Delfino <js...@apache.org> 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/%3c71e1b5740707200331x64d4f6e0tde2a6ae8b0d4d10d@mail.gmail.com%3e
> >
> >
>
> 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
Re: Conversational - spec question
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 7/21/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> ant elder wrote:
>> > On 7/20/07, Jean-Sebastien Delfino <js...@apache.org> 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/%3c71e1b5740707200331x64d4f6e0tde2a6ae8b0d4d10d@mail.gmail.com%3e
>
>
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?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Conversational - spec question
Posted by ant elder <an...@apache.org>.
On 7/21/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > On 7/20/07, Jean-Sebastien Delfino <js...@apache.org> 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/%3c71e1b5740707200331x64d4f6e0tde2a6ae8b0d4d10d@mail.gmail.com%3e
Re: Conversational - spec question
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 7/20/07, Jean-Sebastien Delfino <js...@apache.org> 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?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Conversational - spec question
Posted by ant elder <an...@apache.org>.
On 7/20/07, Jean-Sebastien Delfino <js...@apache.org> 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
Re: Conversational - spec question
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 7/20/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> Simon Laws wrote:
>> > On 7/20/07, Mike Edwards <mi...@gmail.com> wrote:
>> >>
>> >> Folks,
>> >>
>> >> It is clear from reading other sections of the specification that
>> it is
>> >> intended that @ConversationID is used in implementation classes other
>> >> than those of CONVERSATION scope.
>> >>
>> >> Further down in 1.2.51 of the JavaComponentImplementation spec, it
>> says
>> >> the following:
>> >>
>> >> 1. The implementation can be built as a stateless piece of code
>> >> (essentially, the code expects a new instance of the code to be used
>> for
>> >> each method invocation). The code must then be responsible for
>> >> accessing the conversationID of the conversation, which is maintained
>> by
>> >> the SCA runtime code. The implementation is then responsible for
>> >> persisting any necessary state data during the processing of a method
>> >> and for accessing the persisted state data when required, all
>> using the
>> >> conversationID as a key.
>> >>
>> >>
>> >>
>> >> This is clear that stateless (ie NOT CONVERSATION scope)
>> implementations
>> >> can use the conversationID.
>> >>
>> >> So I think that @ConversationID is always actioned - the only
>> difference
>> >> is how often it gets actioned (a CONVERSATION scoped implementation
>> gets
>> >> it just the once, while every invocation of a stateless will require
>> >> injection).
>> >>
>> >>
>> >> Yours, Mike.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >> Thanks Mike
>> >
>>
>> So if I understand correctly:
>> - a stateless-scoped component is injected with the conversation id when
>> the request is presented to it
>> - a composite-scoped component is injected with the conversation id when
>> the request is presented to it
>> - a conversation-scoped component is injected once with the conversation
>> id when it's created (I see this as an optimization)
>>
>> I was assuming that we were not going to present concurrent requests to
>> a composite-scoped component (we should serialize them), so it shouldn't
>> be a problem? However, I couldn't find a statement in the spec about
>> serialization of concurrent requests targeting composite-scoped
>> components. Can a composite-scoped component be presented with
>> concurrent requests?
>
>
> The current code allows concurrent requests to composite scoped
> components.
I think that there is a significant programming model question here,
which I why I started to poke at this... We need to get this clarified
by the spec (unless it's already described and I missed it). I'd suggest
deferring the implementation of @ConversationID, @Context (for
RequestContext) and @Callback on Composite-scoped components until we
have a clear view of the expected programming model, and (putting my app
developer hat on) it's not clear to me at the moment if:
- The business logic in my composite-scoped component is guaranteed that
only one request at a time gets presented to it, saving me from having
to deal with multithreading in my business logic
or
- 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...
> Also, the current code only injects things like @ConversationId when the
> component impl is instantiated, i've not looked, but expect its not
> completely trivial to have the ConversationId injected on each request
> unless the scope is request.
Right...
> Should i go look at these two thing?
>
> ...ant
>
I'd suggest to resolve the Composite-scoped component programming model
question first.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Conversational - spec question
Posted by ant elder <an...@apache.org>.
On 7/20/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Simon Laws wrote:
> > On 7/20/07, Mike Edwards <mi...@gmail.com> wrote:
> >>
> >> Folks,
> >>
> >> It is clear from reading other sections of the specification that it is
> >> intended that @ConversationID is used in implementation classes other
> >> than those of CONVERSATION scope.
> >>
> >> Further down in 1.2.51 of the JavaComponentImplementation spec, it says
> >> the following:
> >>
> >> 1. The implementation can be built as a stateless piece of code
> >> (essentially, the code expects a new instance of the code to be used
> for
> >> each method invocation). The code must then be responsible for
> >> accessing the conversationID of the conversation, which is maintained
> by
> >> the SCA runtime code. The implementation is then responsible for
> >> persisting any necessary state data during the processing of a method
> >> and for accessing the persisted state data when required, all using the
> >> conversationID as a key.
> >>
> >>
> >>
> >> This is clear that stateless (ie NOT CONVERSATION scope)
> implementations
> >> can use the conversationID.
> >>
> >> So I think that @ConversationID is always actioned - the only
> difference
> >> is how often it gets actioned (a CONVERSATION scoped implementation
> gets
> >> it just the once, while every invocation of a stateless will require
> >> injection).
> >>
> >>
> >> Yours, Mike.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >> Thanks Mike
> >
>
> So if I understand correctly:
> - a stateless-scoped component is injected with the conversation id when
> the request is presented to it
> - a composite-scoped component is injected with the conversation id when
> the request is presented to it
> - a conversation-scoped component is injected once with the conversation
> id when it's created (I see this as an optimization)
>
> I was assuming that we were not going to present concurrent requests to
> a composite-scoped component (we should serialize them), so it shouldn't
> be a problem? However, I couldn't find a statement in the spec about
> serialization of concurrent requests targeting composite-scoped
> components. Can a composite-scoped component be presented with
> concurrent requests?
The current code allows concurrent requests to composite scoped components.
Also, the current code only injects things like @ConversationId when the
component impl is instantiated, i've not looked, but expect its not
completely trivial to have the ConversationId injected on each request
unless the scope is request. Should i go look at these two thing?
...ant
Re: Conversational - spec question
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
scabooz wrote:
> Composite scoped components can have concurrent requests inflight, the
> runtime does not need to serialize for concurrency.
>
> I recall having this conversation during the spec work, but cant find
> verbiage in the specs. FWIW, I recall that for composite scoped
> components, we decided that it was not possible to inject
> @ConversationID nor callback references, AND therefore the
> component implementation would have to use the appropriate API
> which would return the correct info in the context of the request.
>
This seems to be in line with what I'm proposing at the bottom of
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20535.html
Some combinations are not supported, let's get this clarified in the
spec first, and when the behavior is clarified we can implement a check
in Tuscany to enforce it.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Conversational - spec question
Posted by Simon Nash <na...@hursley.ibm.com>.
See inline.
Simon
scabooz wrote:
> Hi guys,
>
> See below
>
> Dave
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Friday, July 20, 2007 1:59 PM
> Subject: Re: Conversational - spec question
>
>
>> Simon Laws wrote:
>>
>>> On 7/20/07, Mike Edwards <mi...@gmail.com> wrote:
>>>
>>>>
>>>> Folks,
>>>>
>>>> It is clear from reading other sections of the specification that it is
>>>> intended that @ConversationID is used in implementation classes other
>>>> than those of CONVERSATION scope.
>>>>
>>>> Further down in 1.2.51 of the JavaComponentImplementation spec, it says
>>>> the following:
>>>>
>>>> 1. The implementation can be built as a stateless piece of code
>>>> (essentially, the code expects a new instance of the code to be used
>>>> for
>>>> each method invocation). The code must then be responsible for
>>>> accessing the conversationID of the conversation, which is
>>>> maintained by
>>>> the SCA runtime code. The implementation is then responsible for
>>>> persisting any necessary state data during the processing of a method
>>>> and for accessing the persisted state data when required, all using the
>>>> conversationID as a key.
>>>>
>>>>
>>>>
>>>> This is clear that stateless (ie NOT CONVERSATION scope)
>>>> implementations
>>>> can use the conversationID.
>>>>
>>>> So I think that @ConversationID is always actioned - the only
>>>> difference
>>>> is how often it gets actioned (a CONVERSATION scoped implementation
>>>> gets
>>>> it just the once, while every invocation of a stateless will require
>>>> injection).
>>>>
>>>>
>>>> Yours, Mike.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>> Thanks Mike
>>>
>>>
>>
>> So if I understand correctly:
>> - a stateless-scoped component is injected with the conversation id
>> when the request is presented to it
>> - a composite-scoped component is injected with the conversation id
>> when the request is presented to it
>> - a conversation-scoped component is injected once with the
>> conversation id when it's created (I see this as an optimization)
>>
>> I was assuming that we were not going to present concurrent requests
>> to a composite-scoped component (we should serialize them), so it
>> shouldn't be a problem? However, I couldn't find a statement in the
>> spec about serialization of concurrent requests targeting
>> composite-scoped components. Can a composite-scoped component be
>> presented with concurrent requests?
>
>
> Composite scoped components can have concurrent requests inflight, the
> runtime does not need to serialize for concurrency.
>
> I recall having this conversation during the spec work, but cant find
> verbiage in the specs. FWIW, I recall that for composite scoped
> components, we decided that it was not possible to inject
> @ConversationID nor callback references, AND therefore the
> component implementation would have to use the appropriate API
> which would return the correct info in the context of the request.
>
I am wondering if we are talking about the same thing here. In my post
I was talking about the destination endpoint that will be used for the
callback. Is there an API to access this information and to direct
a callback to the correct endpoint? How would this be done safely
with almost simultaneous injection of two different callback endpoints
into a composite-scoped component?
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Conversational - spec question
Posted by scabooz <sc...@gmail.com>.
Hi guys,
See below
Dave
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Friday, July 20, 2007 1:59 PM
Subject: Re: Conversational - spec question
> Simon Laws wrote:
>> On 7/20/07, Mike Edwards <mi...@gmail.com> wrote:
>>>
>>> Folks,
>>>
>>> It is clear from reading other sections of the specification that it is
>>> intended that @ConversationID is used in implementation classes other
>>> than those of CONVERSATION scope.
>>>
>>> Further down in 1.2.51 of the JavaComponentImplementation spec, it says
>>> the following:
>>>
>>> 1. The implementation can be built as a stateless piece of code
>>> (essentially, the code expects a new instance of the code to be used for
>>> each method invocation). The code must then be responsible for
>>> accessing the conversationID of the conversation, which is maintained by
>>> the SCA runtime code. The implementation is then responsible for
>>> persisting any necessary state data during the processing of a method
>>> and for accessing the persisted state data when required, all using the
>>> conversationID as a key.
>>>
>>>
>>>
>>> This is clear that stateless (ie NOT CONVERSATION scope) implementations
>>> can use the conversationID.
>>>
>>> So I think that @ConversationID is always actioned - the only difference
>>> is how often it gets actioned (a CONVERSATION scoped implementation gets
>>> it just the once, while every invocation of a stateless will require
>>> injection).
>>>
>>>
>>> Yours, Mike.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>> Thanks Mike
>>
>
> So if I understand correctly:
> - a stateless-scoped component is injected with the conversation id when
> the request is presented to it
> - a composite-scoped component is injected with the conversation id when
> the request is presented to it
> - a conversation-scoped component is injected once with the conversation
> id when it's created (I see this as an optimization)
>
> I was assuming that we were not going to present concurrent requests to a
> composite-scoped component (we should serialize them), so it shouldn't be
> a problem? However, I couldn't find a statement in the spec about
> serialization of concurrent requests targeting composite-scoped
> components. Can a composite-scoped component be presented with concurrent
> requests?
Composite scoped components can have concurrent requests inflight, the
runtime does not need to serialize for concurrency.
I recall having this conversation during the spec work, but cant find
verbiage in the specs. FWIW, I recall that for composite scoped
components, we decided that it was not possible to inject
@ConversationID nor callback references, AND therefore the
component implementation would have to use the appropriate API
which would return the correct info in the context of the request.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Conversational - spec question
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> On 7/20/07, Mike Edwards <mi...@gmail.com> wrote:
>>
>> Folks,
>>
>> It is clear from reading other sections of the specification that it is
>> intended that @ConversationID is used in implementation classes other
>> than those of CONVERSATION scope.
>>
>> Further down in 1.2.51 of the JavaComponentImplementation spec, it says
>> the following:
>>
>> 1. The implementation can be built as a stateless piece of code
>> (essentially, the code expects a new instance of the code to be used for
>> each method invocation). The code must then be responsible for
>> accessing the conversationID of the conversation, which is maintained by
>> the SCA runtime code. The implementation is then responsible for
>> persisting any necessary state data during the processing of a method
>> and for accessing the persisted state data when required, all using the
>> conversationID as a key.
>>
>>
>>
>> This is clear that stateless (ie NOT CONVERSATION scope) implementations
>> can use the conversationID.
>>
>> So I think that @ConversationID is always actioned - the only difference
>> is how often it gets actioned (a CONVERSATION scoped implementation gets
>> it just the once, while every invocation of a stateless will require
>> injection).
>>
>>
>> Yours, Mike.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>> Thanks Mike
>
So if I understand correctly:
- a stateless-scoped component is injected with the conversation id when
the request is presented to it
- a composite-scoped component is injected with the conversation id when
the request is presented to it
- a conversation-scoped component is injected once with the conversation
id when it's created (I see this as an optimization)
I was assuming that we were not going to present concurrent requests to
a composite-scoped component (we should serialize them), so it shouldn't
be a problem? However, I couldn't find a statement in the spec about
serialization of concurrent requests targeting composite-scoped
components. Can a composite-scoped component be presented with
concurrent requests?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Conversational - spec question
Posted by Simon Laws <si...@googlemail.com>.
On 7/20/07, Mike Edwards <mi...@gmail.com> wrote:
>
> Folks,
>
> It is clear from reading other sections of the specification that it is
> intended that @ConversationID is used in implementation classes other
> than those of CONVERSATION scope.
>
> Further down in 1.2.51 of the JavaComponentImplementation spec, it says
> the following:
>
> 1. The implementation can be built as a stateless piece of code
> (essentially, the code expects a new instance of the code to be used for
> each method invocation). The code must then be responsible for
> accessing the conversationID of the conversation, which is maintained by
> the SCA runtime code. The implementation is then responsible for
> persisting any necessary state data during the processing of a method
> and for accessing the persisted state data when required, all using the
> conversationID as a key.
>
>
>
> This is clear that stateless (ie NOT CONVERSATION scope) implementations
> can use the conversationID.
>
> So I think that @ConversationID is always actioned - the only difference
> is how often it gets actioned (a CONVERSATION scoped implementation gets
> it just the once, while every invocation of a stateless will require
> injection).
>
>
> Yours, Mike.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Thanks Mike
Re: Conversational - spec question
Posted by Mike Edwards <mi...@gmail.com>.
Folks,
It is clear from reading other sections of the specification that it is
intended that @ConversationID is used in implementation classes other
than those of CONVERSATION scope.
Further down in 1.2.51 of the JavaComponentImplementation spec, it says
the following:
1. The implementation can be built as a stateless piece of code
(essentially, the code expects a new instance of the code to be used for
each method invocation). The code must then be responsible for
accessing the conversationID of the conversation, which is maintained by
the SCA runtime code. The implementation is then responsible for
persisting any necessary state data during the processing of a method
and for accessing the persisted state data when required, all using the
conversationID as a key.
This is clear that stateless (ie NOT CONVERSATION scope) implementations
can use the conversationID.
So I think that @ConversationID is always actioned - the only difference
is how often it gets actioned (a CONVERSATION scoped implementation gets
it just the once, while every invocation of a stateless will require
injection).
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Conversational - spec question
Posted by Simon Laws <si...@googlemail.com>.
On 7/20/07, ant elder <an...@apache.org> wrote:
>
> On 7/19/07, Simon Laws <si...@googlemail.com> wrote:
> >
> > Can anyone familiar with the conversation aspects of the spec tell me
> what
> > is the specified way to get a conversationId in a stateless service, i.ea
> > service which implements an @Conversational interface but is not
> annotated
> > with
> > @Scope("CONVERSATION").
> >
> > 1 Spec (1.2.5.1 of JavaComponentImplementation) says that classes that
> > are CONVERSATION scoped may use @ConversationID. Doesn't say that those
> > that
> > aren't conversation scoped can't
> > 2 Ability to get component context implies
> > componentContext.getRequestContext
> > ().getServiceReference().getConversation().getConversationId().
> > Could we get conversationId added to the request context?
> >
> > I prefer 1. 2 isn't obviously what you would want to be faced with
> unless
> > we
> > can add more info to request context (although this way is useful if you
> > want to pass a reference to this conversation on to others) .
> >
> > Regards
> >
> > Simon
> >
>
> In the absence of any guidance on this how about we make @ConversationID
> always actioned? Or maybe actioned unless its scope COMPOSITE in which
> case
> it throws some exception?
>
> ...ant
Lets go for always actioned. That's what's working in the code base now and
seems to be the neatest solution.
Simon
Re: Conversational - spec question
Posted by ant elder <an...@apache.org>.
On 7/19/07, Simon Laws <si...@googlemail.com> wrote:
>
> Can anyone familiar with the conversation aspects of the spec tell me what
> is the specified way to get a conversationId in a stateless service, i.e a
> service which implements an @Conversational interface but is not annotated
> with
> @Scope("CONVERSATION").
>
> 1 Spec (1.2.5.1 of JavaComponentImplementation) says that classes that
> are CONVERSATION scoped may use @ConversationID. Doesn't say that those
> that
> aren't conversation scoped can't
> 2 Ability to get component context implies
> componentContext.getRequestContext
> ().getServiceReference().getConversation().getConversationId().
> Could we get conversationId added to the request context?
>
> I prefer 1. 2 isn't obviously what you would want to be faced with unless
> we
> can add more info to request context (although this way is useful if you
> want to pass a reference to this conversation on to others) .
>
> Regards
>
> Simon
>
In the absence of any guidance on this how about we make @ConversationID
always actioned? Or maybe actioned unless its scope COMPOSITE in which case
it throws some exception?
...ant