Even for the stateless case, I would argue it's legal to do the
optimization.
The SCA java spec says:
"283 1.2.4.1. Stateless scope
284 For stateless components, there is no implied correlation between
service requests."
I think it should also be valid to get the same instances for multiple
requests. For JEE stateless sessions, the container usally maintains an
instance pool and pick the instance from pool as needed. So there is only
one request at a time, then there is a good chance that the same instance is
picked.
My understanding of "stateless" is that there is no garauntee that multiple
requests will be routed to the same instance.
Thanks,
Raymond
----- Original Message -----
From: "scabooz" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, September 13, 2007 1:57 PM
Subject: Re: Optimize the reference injection for java components
Comments inline
----- Original Message -----
From: "Mike Edwards" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, September 13, 2007 11:44 AM
Subject: Re: Optimize the reference injection for java components
Simon,
Some comments inline....
Simon Nash wrote:
If I understand this correctly, it would affect the lifecycle of
the target component instance. So when A has a reference to B,
the creation of A currently involves creating and injecting a B proxy
but not a B instance. With this change, I think the creation of A
would involve creating a B instance and injecting a reference to this
B instance into A. And if B references C, this would in turn involve
creating a C instance and injecting its reference into B (and so on).
I think there could be many consequences of this change, some of which
may not be desirable. Creation on first invocation is easy to
understand
and consistent, and I'd be concerned about changing this.
But creation can occur at other times. Scope controls this - COMPOSITE
scope implies creation at deployment time, for example. So you need to
be able to deal with these cases anyway. Creation on first invocation
sounds like only one possible behaviour that must be handled.
Since Raymond has already constrained the scenario to local, injection of
the
instance should be ok for REQUEST, CONVERSATION and COMPOSITE
because they should all be "singletons" during the life of the request
that is
currently in flight. For STATELESS, you're supposed to get a new instance
on every invocation, so I don't think you'd want the optimization in this
case.
A related
consideration is some of the callback cases that currently don't quite
work as I would expect, because injection can only happen when an
instance is created. I think there may be cases where we should be
injecting/binding a callback reference when the forward call is
received and disptached to an instance that already exists, and I'm
working on a use case description for this.
With Raymond's proposal, I think that the instances involved in the call
& callback are well known "in advance" and it should work properly.
Perhaps I'm wrong - and certainly it isn't the way it works today, but it
could be made to work that way.
Two stateless callbacks in a row would invoke two different
stateless instances. I think you need the proxy for these callback
cases also.
I would prefer to defer this change until after 1.0 so that we can
discuss it more fully to consider all the implications, and coordinate
it with resolving the callback issues if we agree that a change is
needed there.
That's a fair point and I tend to agree, since this is an optimisation,
not some fundamental function. I suspect it will take quite a piece of
work to make it run properly in all scenarios.
Simon
---------------------------------------------------------------------
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]
