>>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?
Have you looked at any commonj work manager (JSR-237) implementations? M -----Original Message----- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:01 To: [email protected] Subject: Re: Support for callbacks 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] This message has been checked for all email viruses by MessageLabs. ***************************************************** You can find us at www.voca.com ***************************************************** This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
