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]
