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. 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
