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]
