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
|
