Sorry more comments...it's before all my coffee has been absorbed....
On Sep 28, 2006, at 8:48 AM, Jim Marino wrote:
On Sep 28, 2006, at 8:42 AM, scabooz wrote:
Jim,
Comments below
Dave Booz
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, September 27, 2006 10:11 PM
Subject: Re: interceptors and async invocation
Hi Greg,
Comments below.
On Sep 27, 2006, at 1:32 PM, Greg Dritschler wrote:
In the current implementation the thread switch for an
asynchronous method
invocation occurs after interceptors are given control. Isn't this
backwards?
Won't interceptors need to run on the dispatch thread to
establish transactional and security context, provide
monitoring, etc.?
I don't think so as context will need to be propagated to the
thread the dispatch is made on anyway. Also, the target may be a
composite reference in which case it could be in another VM.
Keeping the thread "switching" in the target invoker simplifies
that case IMO.
I would have thought that an interceptor on the dispatch thread is
the
means by which the context was set.
It is. But there needs to be a propagation to the new thread or to
the binding through the target invoker.
Seems like you'd need them on
both sides of the dispatch in all cases. For a remote dispatch,
the target
would need interceptors to propogate context from the message
to the thread. Maybe you are thinking about some form of
optimization
for the local case?
We're saying the same thing, although I may not have been as clear.
I missed your original point...This would be the job of the target
invoker and the binding. We may need a set of interceptors applied to
the target invoker as well to propagate policy through a particular
binding too if we want to be absolutely flexible but we need to see
how policy shapes up (come on finish it ;-) ). These interceptors
would be specific to the binding since they must know how to
propagate context.
Jim
Greg Dritschler
--------------------------------------------------------------------
-
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]
---------------------------------------------------------------------
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]
