You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Scott Kurz (JIRA)" <de...@tuscany.apache.org> on 2008/10/10 15:21:44 UTC
[jira] Created: (TUSCANY-2635) Pool stateless-scoped Java impl
instances
Pool stateless-scoped Java impl instances
-----------------------------------------
Key: TUSCANY-2635
URL: https://issues.apache.org/jira/browse/TUSCANY-2635
Project: Tuscany
Issue Type: Improvement
Reporter: Scott Kurz
Priority: Minor
I'd like to see if we can pool the stateless instances in order to improve performance. The proxy injection in particular is expensive.
Of course, this assumes that, in a general sense, the references backing the proxies are not being setup with any type of context as they are used. I'm speaking generally since I don't have any specific examples to the contrary... but if there were such examples it would obviously be the key consideration in deciding how to go forward on this, so I'd be interested to hear.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (TUSCANY-2635) Pool stateless-scoped Java impl
instances
Posted by Simon Nash <na...@apache.org>.
Scott Kurz wrote:
> Putting aside conversations, let's discuss another example: property
> injection.
>
> Suppose the user's business logic modifies a stateless instance's
> injected property.
>
> @Property
> protected String currency; // configured via SCDL and injected by container
>
> myMethod() {
> ....
> currency = "blah";
> }
>
> So Dave, I take it you're arguing that, if the container were to pool
> stateless instances, it would be responsible for ensuring that in later
> dispatches of this same instance, the 'currency' property would appear
> as if it were freshly-injected upon the business logic reading its value.
>
> This capability strikes me to be of so little value to the app
> programmer that I think the ideal situation would be for the spec to
> disallow this in the stateless programming model and to say that the
> injected data is read-only.
>
> I don't see how this is a common sense issue either. This is a new
> programming model, with a new choice to be made. Going back to EJB
> again, we see a model where one had to understand the difference between
> instance creation and going in and out of the ready pool between
> dispatches. Maybe you're saying this is obviously undesirably complex,
> but on the flip side here is a component model that was widely used
> which employed these concepts. So I don't see it as too complicated to
> say, "it's stateless, so you don't own the instance, so don't mess with
> the injected instance variables."
>
I'd prefer to keep the stateless programming model simple (so that every
dispatch of a stateless component gets what appears to be a new instance)
and figure out how to reduce the proxy injection overhead. Is the main cost
in doing the injection or constructing the proxy? If it is the latter, and
if the proxy is not conversational, then perhaps we could cache and reuse
these proxies rather than creating a new one for every stateless instance.
Simon
> Scott
>
>
> On Mon, Oct 13, 2008 at 4:01 PM, scabooz <scabooz@gmail.com
> <ma...@gmail.com>> 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 <ma...@gmail.com>
> *To:* dev@tuscany.apache.org <ma...@tuscany.apache.org>
> *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
> <simonslaws@googlemail.com <ma...@googlemail.com>>
> wrote:
>
>
>
> On Fri, Oct 10, 2008 at 4:49 PM, Scott Kurz
> <scottkurz@gmail.com <ma...@gmail.com>> wrote:
>
> OK, So
>
> On Fri, Oct 10, 2008 at 10:08 AM, Simon Laws
> <simonslaws@googlemail.com
> <ma...@googlemail.com>> 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
>
>
>
Re: [jira] Created: (TUSCANY-2635) Pool stateless-scoped Java impl instances
Posted by scabooz <sc...@gmail.com>.
Hi Scott,
Just a couple of clarification points:
(a) My common sense comment was referring to the fact that since pooling is not spec'd, any pooling semantic must be invisible to the app, otherwise portability will suffer.
(b) As far as read only properties/refs, don't forget that an important use case in SCA is the ability to use Java components as SCA component implementations which may have been created before SCA existed. Especially in these cases, but not limited these cases, it is very likely that a Java component may want to modify itself. I agree it is unlikely for a truly stateless component, but I think it's heavy handed to have such a constraint.
(c) Issue-65 in the OASIS spec http://www.osoa.org/jira/browse/JAVA-65 is going to have to face the primary question you are asking.
Dave
----- Original Message -----
From: Scott Kurz
To: dev@tuscany.apache.org
Sent: Monday, October 13, 2008 5:17 PM
Subject: Re: [jira] Created: (TUSCANY-2635) Pool stateless-scoped Java impl instances
Putting aside conversations, let's discuss another example: property injection.
Suppose the user's business logic modifies a stateless instance's injected property.
@Property
protected String currency; // configured via SCDL and injected by container
myMethod() {
....
currency = "blah";
}
So Dave, I take it you're arguing that, if the container were to pool stateless instances, it would be responsible for ensuring that in later dispatches of this same instance, the 'currency' property would appear as if it were freshly-injected upon the business logic reading its value.
This capability strikes me to be of so little value to the app programmer that I think the ideal situation would be for the spec to disallow this in the stateless programming model and to say that the injected data is read-only.
I don't see how this is a common sense issue either. This is a new programming model, with a new choice to be made. Going back to EJB again, we see a model where one had to understand the difference between instance creation and going in and out of the ready pool between dispatches. Maybe you're saying this is obviously undesirably complex, but on the flip side here is a component model that was widely used which employed these concepts. So I don't see it as too complicated to say, "it's stateless, so you don't own the instance, so don't mess with the injected instance variables."
Scott
On Mon, Oct 13, 2008 at 4:01 PM, scabooz <sc...@gmail.com> 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
To: dev@tuscany.apache.org
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 <si...@googlemail.com> wrote:
On Fri, Oct 10, 2008 at 4:49 PM, Scott Kurz <sc...@gmail.com> wrote:
OK, So
On Fri, Oct 10, 2008 at 10:08 AM, Simon Laws <si...@googlemail.com> 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
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
Re: [jira] Created: (TUSCANY-2635) Pool stateless-scoped Java impl instances
Posted by Scott Kurz <sc...@gmail.com>.
Putting aside conversations, let's discuss another example: property
injection.
Suppose the user's business logic modifies a stateless instance's injected
property.
@Property
protected String currency; // configured via SCDL and injected by container
myMethod() {
....
currency = "blah";
}
So Dave, I take it you're arguing that, if the container were to pool
stateless instances, it would be responsible for ensuring that in later
dispatches of this same instance, the 'currency' property would appear as if
it were freshly-injected upon the business logic reading its value.
This capability strikes me to be of so little value to the app programmer
that I think the ideal situation would be for the spec to disallow this in
the stateless programming model and to say that the injected data is
read-only.
I don't see how this is a common sense issue either. This is a new
programming model, with a new choice to be made. Going back to EJB again,
we see a model where one had to understand the difference between instance
creation and going in and out of the ready pool between dispatches. Maybe
you're saying this is obviously undesirably complex, but on the flip side
here is a component model that was widely used which employed these
concepts. So I don't see it as too complicated to say, "it's stateless, so
you don't own the instance, so don't mess with the injected instance
variables."
Scott
On Mon, Oct 13, 2008 at 4:01 PM, scabooz <sc...@gmail.com> 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 <sc...@gmail.com>
> *To:* dev@tuscany.apache.org
> *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 <si...@googlemail.com>wrote:
>
>>
>>
>> On Fri, Oct 10, 2008 at 4:49 PM, Scott Kurz <sc...@gmail.com> wrote:
>>
>>> OK, So
>>>
>>> On Fri, Oct 10, 2008 at 10:08 AM, Simon Laws <si...@googlemail.com>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
>>>
>>> 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
>>
>>
>
Re: [jira] Created: (TUSCANY-2635) Pool stateless-scoped Java impl instances
Posted by scabooz <sc...@gmail.com>.
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
To: dev@tuscany.apache.org
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 <si...@googlemail.com> wrote:
On Fri, Oct 10, 2008 at 4:49 PM, Scott Kurz <sc...@gmail.com> wrote:
OK, So
On Fri, Oct 10, 2008 at 10:08 AM, Simon Laws <si...@googlemail.com> 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
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
Re: [jira] Created: (TUSCANY-2635) Pool stateless-scoped Java impl instances
Posted by Scott Kurz <sc...@gmail.com>.
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 <si...@googlemail.com>wrote:
>
>
> On Fri, Oct 10, 2008 at 4:49 PM, Scott Kurz <sc...@gmail.com> wrote:
>
>> OK, So
>>
>> On Fri, Oct 10, 2008 at 10:08 AM, Simon Laws <si...@googlemail.com>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
>>
>> 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
>
>
Re: [jira] Created: (TUSCANY-2635) Pool stateless-scoped Java impl instances
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Oct 10, 2008 at 4:49 PM, Scott Kurz <sc...@gmail.com> wrote:
> OK, So
>
> On Fri, Oct 10, 2008 at 10:08 AM, Simon Laws <si...@googlemail.com>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
>
> 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
Re: [jira] Created: (TUSCANY-2635) Pool stateless-scoped Java impl instances
Posted by Scott Kurz <sc...@gmail.com>.
OK, So
On Fri, Oct 10, 2008 at 10:08 AM, Simon Laws <si...@googlemail.com>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
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
Re: [jira] Created: (TUSCANY-2635) Pool stateless-scoped Java impl instances
Posted by Raymond Feng <en...@gmail.com>.
Hi,
It seems that EJB3 stateless session has slight different view on how the
init and destroy are invoked. In EJB, the init (@PostConstruct) and destroy
(@PreDestroy) callbacks are only invoked once per stateless session bean
instance. The sequence is:
DI
PostConstruct
Ready to take one or more methods (in the pool, no resetting is required)
m1
m2
m1
...
PreDestroy
We probably need to clarify with SCA spec to understand if SCA follows the
same pattern in this case.
Thanks,
Raymond
From: Simon Laws
Sent: Friday, October 10, 2008 7:08 AM
To: dev@tuscany.apache.org
Subject: Re: [jira] Created: (TUSCANY-2635) Pool stateless-scoped Java impl
instances
On Fri, Oct 10, 2008 at 2:21 PM, Scott Kurz (JIRA) <de...@tuscany.apache.org>
wrote:
Pool stateless-scoped Java impl instances
-----------------------------------------
Key: TUSCANY-2635
URL: https://issues.apache.org/jira/browse/TUSCANY-2635
Project: Tuscany
Issue Type: Improvement
Reporter: Scott Kurz
Priority: Minor
I'd like to see if we can pool the stateless instances in order to improve
performance. The proxy injection in particular is expensive.
Of course, this assumes that, in a general sense, the references backing the
proxies are not being setup with any type of context as they are used.
I'm speaking generally since I don't have any specific examples to the
contrary... but if there were such examples it would obviously be the key
consideration in deciding how to go forward on this, so I'd be interested to
hear.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
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
Re: [jira] Created: (TUSCANY-2635) Pool stateless-scoped Java impl instances
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Oct 10, 2008 at 2:21 PM, Scott Kurz (JIRA)
<de...@tuscany.apache.org>wrote:
> Pool stateless-scoped Java impl instances
> -----------------------------------------
>
> Key: TUSCANY-2635
> URL: https://issues.apache.org/jira/browse/TUSCANY-2635
> Project: Tuscany
> Issue Type: Improvement
> Reporter: Scott Kurz
> Priority: Minor
>
>
> I'd like to see if we can pool the stateless instances in order to improve
> performance. The proxy injection in particular is expensive.
>
> Of course, this assumes that, in a general sense, the references backing
> the proxies are not being setup with any type of context as they are used.
> I'm speaking generally since I don't have any specific examples to the
> contrary... but if there were such examples it would obviously be the key
> consideration in deciding how to go forward on this, so I'd be interested to
> hear.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
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
[jira] Closed: (TUSCANY-2635) Pool stateless-scoped Java impl
instances
Posted by "ant elder (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ant elder closed TUSCANY-2635.
------------------------------
Resolution: Fixed
Thanks for the fix Greg, applied in trunk at r709171 and 1.3.3 branch at r709180.
> Pool stateless-scoped Java impl instances
> -----------------------------------------
>
> Key: TUSCANY-2635
> URL: https://issues.apache.org/jira/browse/TUSCANY-2635
> Project: Tuscany
> Issue Type: Improvement
> Reporter: Scott Kurz
> Assignee: ant elder
> Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: tuscany-2635.patch
>
>
> I'd like to see if we can pool the stateless instances in order to improve performance. The proxy injection in particular is expensive.
> Of course, this assumes that, in a general sense, the references backing the proxies are not being setup with any type of context as they are used. I'm speaking generally since I don't have any specific examples to the contrary... but if there were such examples it would obviously be the key consideration in deciding how to go forward on this, so I'd be interested to hear.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2635) Pool stateless-scoped Java impl
instances
Posted by "Greg Dritschler (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642658#action_12642658 ]
Greg Dritschler commented on TUSCANY-2635:
------------------------------------------
Concerns have been raised on the mailing list regarding pooling component instances, such as when to call the lifecycle methods @Init, @Destroy, whether to reinitialize instance variables, etc. In order to avoid these issues, an alternative solution to the expense of proxy injection has been found. I have attached a patch.
> Pool stateless-scoped Java impl instances
> -----------------------------------------
>
> Key: TUSCANY-2635
> URL: https://issues.apache.org/jira/browse/TUSCANY-2635
> Project: Tuscany
> Issue Type: Improvement
> Reporter: Scott Kurz
> Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: tuscany-2635.patch
>
>
> I'd like to see if we can pool the stateless instances in order to improve performance. The proxy injection in particular is expensive.
> Of course, this assumes that, in a general sense, the references backing the proxies are not being setup with any type of context as they are used. I'm speaking generally since I don't have any specific examples to the contrary... but if there were such examples it would obviously be the key consideration in deciding how to go forward on this, so I'd be interested to hear.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2635) Pool stateless-scoped Java impl
instances
Posted by "Greg Dritschler (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Greg Dritschler updated TUSCANY-2635:
-------------------------------------
Attachment: tuscany-2635.patch
> Pool stateless-scoped Java impl instances
> -----------------------------------------
>
> Key: TUSCANY-2635
> URL: https://issues.apache.org/jira/browse/TUSCANY-2635
> Project: Tuscany
> Issue Type: Improvement
> Reporter: Scott Kurz
> Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: tuscany-2635.patch
>
>
> I'd like to see if we can pool the stateless instances in order to improve performance. The proxy injection in particular is expensive.
> Of course, this assumes that, in a general sense, the references backing the proxies are not being setup with any type of context as they are used. I'm speaking generally since I don't have any specific examples to the contrary... but if there were such examples it would obviously be the key consideration in deciding how to go forward on this, so I'd be interested to hear.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TUSCANY-2635) Pool stateless-scoped Java impl
instances
Posted by "ant elder (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ant elder reassigned TUSCANY-2635:
----------------------------------
Assignee: ant elder
> Pool stateless-scoped Java impl instances
> -----------------------------------------
>
> Key: TUSCANY-2635
> URL: https://issues.apache.org/jira/browse/TUSCANY-2635
> Project: Tuscany
> Issue Type: Improvement
> Reporter: Scott Kurz
> Assignee: ant elder
> Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: tuscany-2635.patch
>
>
> I'd like to see if we can pool the stateless instances in order to improve performance. The proxy injection in particular is expensive.
> Of course, this assumes that, in a general sense, the references backing the proxies are not being setup with any type of context as they are used. I'm speaking generally since I don't have any specific examples to the contrary... but if there were such examples it would obviously be the key consideration in deciding how to go forward on this, so I'd be interested to hear.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2635) Pool stateless-scoped Java impl
instances
Posted by "ant elder (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ant elder updated TUSCANY-2635:
-------------------------------
Fix Version/s: Java-SCA-Next
> Pool stateless-scoped Java impl instances
> -----------------------------------------
>
> Key: TUSCANY-2635
> URL: https://issues.apache.org/jira/browse/TUSCANY-2635
> Project: Tuscany
> Issue Type: Improvement
> Reporter: Scott Kurz
> Priority: Minor
> Fix For: Java-SCA-Next
>
>
> I'd like to see if we can pool the stateless instances in order to improve performance. The proxy injection in particular is expensive.
> Of course, this assumes that, in a general sense, the references backing the proxies are not being setup with any type of context as they are used. I'm speaking generally since I don't have any specific examples to the contrary... but if there were such examples it would obviously be the key consideration in deciding how to go forward on this, so I'd be interested to hear.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.