Re: [Springframework-developer] EJB access improvements

[Colin S. <col...@ex...>]

I'll add some code in the little EJB test app in the autobuilds tree.=20
Hapilly enough, in the main project at work where there used to be lots=20
of EJBs they have all been exorcised with the exception of some Message=20
Driven Beans, which are innocent enough, so I can't actually test this=20
in production any longer...

Colin


j=FCrgen h=F6ller [werk3AT] wrote:

>Colin,
>=20
>I've just committed the changes. Please give them a try!
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n Colin Sampaleanu
>Gesendet: Mo 17.05.2004 23:50
>An: spr...@li...
>Betreff: Re: [Springframework-developer] EJB access improvements
>
>
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
> =20
>
>>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 "rem=
ove" won't actually remove an instance - as SLSBs are pooled.
>>
>>However, we can easily invoke "remove" on the EJB proxy after the metho=
d call, both in SimpleRemoteSlsbInvokerInterceptor and in LocalSlsbInvoke=
rInterceptor. It seems that this can happen in any case: A typical contai=
ner 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. I=
f turned off, the home object will be refetched on each method invocation=
. This is intended for development environments: It allows for hot redepl=
oy 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 e=
ither 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 =
mentioned 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
>the home will suite some people even for non-development situations.
>Other people are not going to be very happy with that situation however.
>A sequence that without Spring would have been a home lookup followed by
>maybe 5 invocations on the same session stub now becomes 5 home lookups
>and 5 create calls, for the 5 method calls. So I am open to us adding in
>one of the other two solutions to make these people happy, post 1.0.2.
>
>Colin
> =20
>