Simon, I'm assuming there's value in the simplicity of the single-threaded programming model that you get with stateless components. Perhaps you want to use some non-thread-safe resource and would rather not have to manage control of it. The fact that stateless is the default is an added reason it would be nice to make this well-performing.
So you mentioned security context. Could you flesh out a bit what an example concern would be here? This is the type of feedback I was looking for, so thank you. As far as @Init... if I recall the spec says that it gets called on a scope boundary, which doesn't actually buy us anything for stateless components (unlike ejbCreate() for a SLSB, say), but the proxy injection is a bit expensive. Scott On Mon, Oct 6, 2008 at 12:28 PM, Simon Laws <[EMAIL PROTECTED]>wrote: > > > On Mon, Oct 6, 2008 at 4:56 PM, Scott Kurz <[EMAIL PROTECTED]> wrote: > >> I was wondering if there were any reason why trying to introduce pooling >> of stateless-scoped instances would be non-trivial. >> (I don't believe we are doing this today; instead we create a new instance >> each time.) >> >> Otherwise I was planning to give it a try, after noticing specifically >> that the reference proxy injection is slow. >> >> I realize there are considerations, when, say, a stateless component has a >> reference with a conversational-interface, since the spec >> says that ref injection begins a conversation. >> >> However if you're using stateless components, you should clearly know that >> the container may or may not give you a new instance, so >> if you choose to inject a ref. to a conversational intf then you leave it >> up to the container to start a new conversation when it creates a new >> stateless instance. So I don't see this as a problem. >> >> Would be interesting to hear other concerns before prototyping. >> >> Thanks, >> Scott >> > > Hi Scott > > Interesting. Do you intend to re-use a stateless component in its > constructed state, i.e. with all references injected and @Init methods > called? It seems to me you would have to be really careful. The creation of > a component may have set up some context within which service operations run > that will only be valid for that client, e.g. a security context. If you > want to ensure that the component instance is re-used why wouldn't you just > use a composite scoped component? > > Simon >
