Scott
On Mon, Oct 13, 2008 at 4:01 PM, scabooz <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi guys,
I'm having a hard time following this latest branch in the
discussion, but I think there is a basic principle that needs to be
asserted, which is that instance pooling must be unobservable to the
business logic. This is just common sense, and anything else will
make the programming model more difficult to understand. More
specifically, when the runtime hands an instance to the business
logic, the state of that instance should be identical regardless of
whether the container new-ed up the instance or obtained it from a pool.
Someone is going to jump on the "where does it say that in the
spec?" question. It's probably not explicit, but it should be, and
there are open issues in the OASIS work to clarify and lock it
down. All I can say to this question is that the above is the spec
intention, and is a principle that will cause the least surprise and
most success for users.
Dave
----- Original Message -----
*From:* Scott Kurz <mailto:[EMAIL PROTECTED]>
*To:* [email protected] <mailto:[email protected]>
*Sent:* Friday, October 10, 2008 4:16 PM
*Subject:* Re: [jira] Created: (TUSCANY-2635) Pool
stateless-scoped Java impl instances
Simon,
Sorry my line of reasoning didn't come through so well.
I was actually trying to argue the point that a new conversation
should NOT be started just because a stateless instance is
obtained from a pool.
However, I was trying to address the opposite point of view (a
new conversation should be started), which I think is where you
were coming from.
If the specs had said something like "at the beginning of a
scope, references are injected", then we'd have an answer
(opposite to my reading). If you take Java C&I lines 193-195
to mean the same, we'd also contradict my interpretation.
In contrast, I'm taking the lack of clarity as a signal that
this is up to the runtime implementation to work out So the
net is (per my reading), that you can not assume a new
conversation per stateless dispatch, if you're relying on
reference injection to start the conversation....and you have to
use programmatic means if you want this.
Scott
On Fri, Oct 10, 2008 at 12:18 PM, Simon Laws
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:
On Fri, Oct 10, 2008 at 4:49 PM, Scott Kurz
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
OK, So
On Fri, Oct 10, 2008 at 10:08 AM, Simon Laws
<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Scott
Can you say a little more about what the
implications for pooling stateless instances would
be, for example,
1st call - Create object
@Reference injected
@Init run
1st Operation execution ends
@Destory called
Reset any conversational/callback state help in
the components references
object put in pool
2nd call - Retrieve object from pool
@Init called
2nd Operation execution ends
@Destory called
Reset any conversational/callback state help in
the components references
object put in pool
Is that the sort of thing you were thinking of in
order to remove the injection overhead?
Simon, yes, unlike, say ejbCreate() for a SLSB, the
@Init is supposed to get called every time for a
stateless invocation
So let's look at conversational state, which is the type
of concern I was hoping to get to. I'm pretty
ignorant of what this looks like at a low level. At a
high level, though, a new conversation is supposed to
begin every time a conversational-interfaced-reference
is injected into the client component.
So, my naive take on this would be that this isn't all
that useful when the client component is stateless,
since you don't know when the container is going to give
you a new stateless instance (with an
already-started-conversation) or an existing one.
So if you need better control over starting a
conversation from a stateless component, you need to get
your conversational reference programmatically.
I suppose you could read into the specs the idea that
they intended the references to be injected at the start
of the scope..... there is this (which I don't believe
helps):
Java C&I - 1.2.2.1 <http://1.2.2.1>
192 If @Reference marks a public or protected field, the
SCA runtime is required to provide the appropriate
193 implementation of the service reference contract as
specified by the field type. This must done by setting
194 the field on an implementation instance. When
injection occurs is defined by the scope of the
195 implementation.
I don't think it helps since I don't see that the specs
define this with respect to the Java impl scopes.
So... given that my model is, we don't really consider
this is a smart use case and we leave the conversation
dangling in such a case... do we still have anything to
worry about for conversations?
Scott
Hi
If you did read into the specs that injection was intended
to happen at the start of each scope, i.e. in this case when
an object is retrieved from the pool, wouldn't that kill the
performance improvement you are looking to achieve?
Not sure I understand the last sentence.
So... given that my model is, we don't really consider this
is a smart use case and we leave the conversation dangling
in such a case... do we still have anything to worry about
for conversations?
If you don't clean up the conversation object then when you
call through the reference of a previously pooled component
instance you will likely be continuing a conversation that
is already started. There is state referenced behind the
reference proxy and also in the conversation manager about
onging conversations. This state is removed when a component
instance is removed and we'd have to work out how to do the
same if we were to pool stateful instances. This is of
course in the case where the business logic doesn't end the
conversation properly itself.
Simon
