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?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
