Hi Ignacio,
Sorry about the delay...Comments inline. I've also added some
scenarios to the wiki so feel free to add your thoughts to them.
Jim
On Jul 5, 2006, at 2:07 PM, Ignacio Silva-Lepe wrote:
Hi Jim,
Sorry about the disconnect, I was out Monday and yesterday. I'll be
sure to
attend the IRC chat tomorrow. In the meantime, some more quick
comments.
----- Original Message ----- <snip/>
If I understand correctly, would a system service transport use
a low level
communication mechanism, like a socket for instance? This does
not seem like
an appropriate approach for a local scenario,
Right, for the local scenario, I was thinking the callback
instance would be put on the thread local context and the proxy
would access it from there as opposed to going out over a socket
and back in through a listener. Basically, it would be an
optimization of the remote case. I think we can further optimize
things depending on scopes, e.g. if the callback scope is
"module", we could possibly avoid threadlocal storage and have
the proxy hold on to an instance directly.
Pointing at the callback instance directly from the proxy would
eliminate
invocation chains and the ability to add interceptors to them,
wouldn't it?
Yea the proxy should probably point back to the Component and not the
instance directly unless there is an optimized case where no
interceptors were present. Once the proxy points to Component, it can
call getInboundWire(String serviceName) which will return the
invocation chain that will dispatch to the correct instance. In the
case of an AtomicComponent, when the end of the chain is reached, the
target invoker will delegate to the scope container which will return
the right instance.
Also, I'm not sure using a thread local in the core is a good idea
if an
intention is to allow the core to be embeddable in, for instance, a
managed
environment, as thread local does not necessarily mix well with thread
pools.
Good point. I think a similar mechanism may be o.k. as long as we
clean up properly when the request ends or the thread is reclaimed
(e.g. in case of failure where the callback never hapens). Perhaps we
could use the WorkArea API for this? Were you thinking of something
in particular?
Jim
<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]
