Maybe I wasn't clear from this post...I don't think it can.
Invocation handlers are per operation as well so they can't share
state that is per client. The semantics of start/continue/stop are
that multiple operations could call start and the client needs to
track where it is in the conversation. So, we need a marker for if
the conversation has begun for the client instance. Right now,
invocation handlers don't have per-client state and this really seems
like a different concern than an invocation handler, which is to
create a message and fire it down the chain. Do you think it would be
better to have the start/continue interceptor per chain and have
interceptor instances share a marker per wire (I just sent another
note on that)?
Jim
On Dec 4, 2006, at 9:24 AM, Ignacio Silva-Lepe wrote:
Yeah, my current feeling is that the invocation handler can keep
track of the state of the conversation as well as the interceptor
does at the moment.
On 12/4/06, Jim Marino <[EMAIL PROTECTED]> wrote:
The problem with moving this into the invocation handler is that we
need a mechanism to track state for whether the client believes the
conversation has begun. For example:
interface ConverSationalService {
void operation1();
void operation2();
void end();
}
Calling operation1 or operation2 will start the conversation, and
subsequent calls to those two will continue the conversation. We will
need to come up with a mechanism for handling this. Are you proposing
to create a type of key class that contains the conversational key
value and a flag of its sequence? If we do this, we can continue to
use the interceptors as they become stateless.
Jim
On Dec 4, 2006, at 6:50 AM, Ignacio Silva-Lepe wrote:
> As it turns out, there's a problem with 7 below. The key to a
> ConversationSequenceInterceptor is that the same instance is
> used for all conversational operations except the ones that end
> the conversation, with this instance maintaining a flag to
determine
> whether the conversation is starting or not. However, since
> interceptors are part of a chain, if we try to use a single
instance
> of a given interceptor for more than one operation, we are
effectively
> merging the corresponding chains at the point the interceptor is
> inserted. In our case, the interceptor is being inserted at the
head,
> so we basically bypass all other interceptors for all chains but
the
> last one. In the sample, one of the operations happens to be one-
way
> but its non-blocking interceptor is being bypassed and so we lose
> its async behavior.
> I am checking in a fix that moves the behavior provided by the
> conversational interceptors (as well as the wire post processor) to
> the AbstractOutboundInvocationHandler and that disables the wire
> post processor by removing its entry from core/implementation.scdl.
>
>
> On 11/27/06, Jim Marino <[EMAIL PROTECTED]> wrote:
> <snip/>
>
>>
>> 7. I added two interceptors that will be inserted into invocation
>> chains between conversational implementations.
>> ConversationSequenceInterceptor will be inserted into all
operations
>> except ones marked @EndConversation. This interceptor tracks the
>> conversation sequence the operation is invoked in (start or
>> continue). This is necessary so the scope container knows
whether to
>> create a new instance or return an existing one (since
conversation
>> ids may be reused). Each operation for a wire receives the same
>> instance of the ConversationSequenceInterceptor, which is
inserted in
>> the wire post-process phase by ConversationWirePostProcessor. For
>> operations marked with @EndConversation, a
ConversationEndInterceptor
>> is inserted.
>
>
> <snip/>
>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
