ant elder wrote:
On 7/20/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Simon Laws wrote:
> On 7/20/07, Mike Edwards <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
