Re: [Springframework-developer] EJB access improvements

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

Juergen,

I added a test with and without the cache, and it seems to work fine.  
CVS is acting up a bit now, so I'll check in the stuff later...


Colin Sampaleanu wrote:

> I'll add some code in the little EJB test app in the autobuilds tree. 
> Hapilly enough, in the main project at work where there used to be 
> lots of EJBs they have all been exorcised with the exception of some 
> Message Driven Beans, which are innocent enough, so I can't actually 
> test this in production any longer...
>
> Colin
>
>
> jürgen höller [werk3AT] wrote:
>
>> Colin,
>>
>> I've just committed the changes. Please give them a try!
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: spr...@li... im Auftrag 
>> von Colin Sampaleanu
>> Gesendet: Mo 17.05.2004 23:50
>> An: spr...@li...
>> Betreff: Re: [Springframework-developer] EJB access improvements
>>
>>
>>
>> jürgen höller [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 "remove" won't actually remove an instance - as SLSBs are pooled.
>>>
>>> However, we can easily invoke "remove" on the EJB proxy after the 
>>> method call, both in SimpleRemoteSlsbInvokerInterceptor and in 
>>> LocalSlsbInvokerInterceptor. It seems that this can happen in any 
>>> case: A typical container 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 redeploy 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 either 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
>>>
>>>
>>>   
>>
>> 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
>>   
>