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]>wrote: > > > On Fri, Oct 10, 2008 at 4:49 PM, Scott Kurz <[EMAIL PROTECTED]> wrote: > >> OK, So >> >> On Fri, Oct 10, 2008 at 10:08 AM, Simon Laws <[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 >> >> 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 > >
