I tried using separate instances, but they all need to share the
common knowledge of the conversation's state. I suppose they
could all be given a single object encapsulating this knowledge,
but at the time it seemed to me to complicate matters, as it
seems to me we already have one such common object, the
invocation handler.
In addition, if we end up deciding to keep the interceptors, we
should also make sure that they are inserted at a single set
of chains along the path between client and service.
On 12/4/06, Jim Marino <[EMAIL PROTECTED]> wrote:
Thinking abut this some more...Shouldn't we just insert different
instances of the start/continue interceptor and have those instances
share a common marker for the wire? The end conversation interceptor
would remain the same. I'm trying to avoid placing more logic in the
handlers (which are already kind of bloated) since this is a separate
concern.
Jim
On Dec 4, 2006, at 8:32 AM, Jim Marino 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]
