Hmm, maybe I am missing something, but doesn't an
invocation handler get called for any operation and then it
decides what chain to follow?
On 12/4/06, Jim Marino <[EMAIL PROTECTED]> wrote:
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]
