Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-05-18 07:57:15
|
Colin, =20 I've just committed the changes. Please give them a try! =20 Juergen =20 ________________________________ 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=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 = "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 >=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 ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62&alloc_ida84&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-05-18 13:33:15
|
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 > |
|
From: Colin S. <col...@ex...> - 2004-05-19 12:13:32
|
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 >> > |
