|
From: Colin S. <col...@ex...> - 2004-05-17 21:51:07
|
j=FCrgen h=F6ller [werk3AT] wrote: >Colin, Rod, > >Regarding the following two issues: > >http://opensource.atlassian.com/projects/spring/browse/SPR-117 > >Actually, the contract for Stateless Session Beans is quite odd in that = respect: You don't really "create" a SLSB with a "create" call, and "remo= ve" won't actually remove an instance - as SLSBs are pooled.=20 > >However, we can easily invoke "remove" on the EJB proxy after the method= call, both in SimpleRemoteSlsbInvokerInterceptor and in LocalSlsbInvoker= Interceptor. It seems that this can happen in any case: A typical contain= er will simply ignore the "remove" call anyway. > >http://opensource.atlassian.com/projects/spring/browse/SPR-129 > >I've just added a "cacheHome" flag to AbstractSlsbInvokerInterceptor. If= turned off, the home object will be refetched on each method invocation.= This is intended for development environments: It allows for hot redeplo= y of the target EJB respectively restart of the EJB container. > > >I've just added the corresponding code, as it shouldn't change anything = in typical cases. I'll commit it by tomorrow morning. If you object to ei= ther of these changes, we can still roll them back before 1.0.2. > >For addressing the second issue, there are a couple of further options m= entioned in the JIRA entry: for example, refetching the home object when = the create invocation fails. However, those are probably beyond 1.0.2. > >Juergen > =20 > This is fine. My feeling is that the ability to turn off the cache for=20 the home will suite some people even for non-development situations.=20 Other people are not going to be very happy with that situation however.=20 A sequence that without Spring would have been a home lookup followed by=20 maybe 5 invocations on the same session stub now becomes 5 home lookups=20 and 5 create calls, for the 5 method calls. So I am open to us adding in=20 one of the other two solutions to make these people happy, post 1.0.2. Colin |