looking to try stateless-scoped impl instance pooling

[Scott Kurz <sc...@gmail.com>]

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

Re: looking to try stateless-scoped impl instance pooling

[Scott Kurz <sc...@gmail.com>]

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 <si...@googlemail.com>wrote:

>
>
> On Mon, Oct 6, 2008 at 4:56 PM, Scott Kurz <sc...@gmail.com> 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
>

Re: looking to try stateless-scoped impl instance pooling

[Simon Laws <si...@googlemail.com>]

On Mon, Oct 6, 2008 at 4:56 PM, Scott Kurz <sc...@gmail.com> 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