See inline.
Simon
scabooz wrote:
Hi guys,
See below
Dave
----- Original Message ----- From: "Jean-Sebastien Delfino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, July 20, 2007 1:59 PM
Subject: Re: Conversational - spec question
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?
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
