Menu
▾
▴
Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator
|
From: <jue...@we...> - 2004-08-30 13:52:42
|
I agree that "lookupHomeOnStartup"=3Dfalse would be a sensible default. = Its only disadvantage, aside from backwards compatibility, is that it = requires a synchronized block for accessing the home object, which could = have negative effects in a highly concurrent environment. The current implementation tries to avoid synchronization wherever it = can: In particular, "lookupHomeOnStartup"=3Dtrue does not use = synchronization unless you also specified "refreshHomeOnConnectFailure". = Same goes for RmiClientInterceptor and JndiRmiClientInterceptor. That said, I still recommend to specify "lookupHomeOnStartup"=3Dfalse = and "refreshHomeOnConnectFailure"=3Dtrue in the usual case, to allow for = both lazy home lookup and automatic refresh/retry if the home became = stale (for example, after a restart of the target server). Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Colin Sampaleanu Sent: Sunday, August 29, 2004 5:21 PM To: spr...@li... Subject: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator I think the enhancements are going to help people. From reading your=20 mail below (haven't looked at the code yet), it sounds like the=20 lookupHomeOnStartup option is on by default. I know that this makes the=20 code completely backwards compatible, but IMHO it probably makes more=20 sense to have it default to off. In a lot fo containers you had to use=20 the lazy-init=3Dtrue setting on the bean previously so you wouldn't = access=20 the ejbs before they were actually loaded, so I think most users will=20 want this on by default. Of course, there are some people who will get=20 an error message (on bad setup) later rather than sooner with this=20 setup, but I think it's going to be less people than get burned by the=20 fact their EJBs are not loaded yet. I'll update the ejbtest integration test/sample at a minimum to test=20 some of the new options. I should be able to update the ejb docs to=20 mention the new options. j=FCrgen h=F6ller [werk3AT] wrote: >Forget to mention that I've also refactored = AbstractRemoteSlsbInvokerInterceptor and = SimpleRemoteSlsbInvokerInterceptor: Subclassing for other proxy fetching = strategies (as opposed to home fetching strategies) should be = straightforward now. >=20 >For example, SimpleRemoteSlsbInvokerInterceptor could be subclassed = with "getSessionBeanInstance" and "releaseSessionBeanInstance" getting = overridden to work on a shared SLSB proxy instance, rather than creating = one for each invocation. The SLSB proxy could be created in an = "afterPropertiesSet" implementation (calling "newSessionBeanInstance") = and removed in a "destroy" implementation (calling = "removeSessionBeanInstance"). >=20 >In total, all defaults should behave just like before, but I believe = that the new EJB access options (particularly lazy lookup and refresh on = connect failure) provide significant value for typical usage scenarios. = And the new RMI options increase the value of standalone RMI as remoting = strategy, making them a more credible alternative to HTTP-based = remoting. >=20 >Colin, what's your view on these changes? We should discuss any issues = ASAP, to be able to release 1.1 final by the end of the coming week. It = would also be great to discuss those options briefly in the reference = manual - do you maybe have the chance to add some brief paragraphs on = them? >=20 >Juergen >=20 > >________________________________ > >Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] >Gesendet: So 29.08.2004 16:27 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator > > > >Everything's committed since Friday. Everybody who has the chance, = please give the new options a try, in particular the new EJB access = options. I've tested the RMI options quite a bit, but not had a chance = to play with the EJB options yet. > >* AbstractSlsbInvokerInterceptor has a new "lookupHomeOnStartup" option = (alongside the existing "cacheHome"): Turn it off to get lazy fetching = of the EJB home, on first access, caching the home from then on. The = interceptor respectively proxy bean can still be initialized eagerly, so = there's no need to mark its bean definition as "lazy-init". > >* AbstractRemoteSlsbInvokerInterceptor has a new = "refreshHomeOnConnectFailure" option: Turn it on to automatically = refresh the home and retry if a call resulted in a = java.rmi.ConnectException. This should work without side effects, as = ConnectException should just be thrown if no socket connection to the = target server could be established: Retrying the call with a fresh EJB = home should be a safe operation in that case. The default is off, = though. > >* RmiClientInterceptor and JndiRmiClientInterceptor have analogous = "lookupRmiProxyOnStartup", "cacheRmiProxy" and = "refreshRmiProxyOnConnectFailure" options. By default, the first two = options are on and the latter is off. Those can in principle be combined = in any way, as they are independent to a large degree. The refresh = option behaves similarly to with EJB homes: It refreshes and retries on = java.rmi.ConnectException. > >So there are two main new features for EJB and RMI: lazy initialization = of a cached EJB home without resorting to defining the bean as = "lazy-init", and refreshing the EJB home object respectively RMI proxy = if it became stale. The latter allows for hot restarts of the EJB = respectively RMI server without restarting the client, no matter whether = the EJB home supports auto-failover itself. > >This brings the EJB and RMI support to the same convenience level as = the HTTP-based protocols (Hessian, Burlap, HTTP invoker): Starting up = the remote server later than the client or restarting the remote server = without restarting the client does not pose a problem for HTTP-based = remoting in the first place, as there is no proxy holding a connection = that could become stale there. Therefore, the above options are not = necessary for the HTTP remoting support in the first place. > >Juergen > > > >________________________________ > >Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] >Gesendet: Mi 25.08.2004 21:23 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator > > > >I've basically finished the reworked proxy fetching stuff: = RmiClientInterceptor, JndiRmiClientInterceptor and = AbstractSlsbInvokerInterceptor all support the four fetching strategies = I've mentioned, through two flags (look proxy up on startup, cache = proxy). As those accessors are capable of refetching the proxy now, we = can also easily allow for further strategies, for example to check a = proxy and refetch if it is broken (with custom check implementation). > >I've also added a JndiObjectTargetSource that can be used to refetch a = JNDI object for each call. It supports two analogous flags, so the = actual fetching strategy can be customized. I've tested this with an = OpenJMS ConnectionFactory: By defining it as ProxyFactoryBean plus = JndiObjectTargetSource instead of a JndiObjetcFactoryBean, each = createConnection call can trigger a fresh JNDI lookup to make sure that = the ConnectionFactory reference is valid. > >While refetching of RMI proxies and JNDI objects for each operation of = course represents a significant overhead, it's not too bad if the = respective objects are rarely used. I still rather consider this as = development feature, though, to allow restarting of remote processes = while keeping the clients alive. Lazily initializing the references is a = good feature for production too: The remote processes do not have to be = alive when the clients start up then. > >I'll commit all of that stuff tomorrow, after having gone through it in = terms of documentation etc. I'll also put some further thought into = custom refetching strategies, providing appropriate hooks for = subclasses. In the future, we might introduce an appropriate strategy = interface for that. > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag = von Colin Sampaleanu >Gesendet: Mi 25.08.2004 15:08 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator > > > >j=FCrgen h=F6ller [werk3AT] wrote: > > =20 > >>One further thing: JndiObjectFactoryBean currently returns its located = object as-is for the entire lifetime of the client application: If the = located object becomes broken at some point of time (which can happen, = for example, to an SFSB home or a JMS Destination), clients will carry = an unusable reference from then on. Our remoting accessors, on the other = hand, expose the same remote service proxy all the time, being able to = delegate calls to changing backend stubs (for example, refetched SLSB = homes). >> >>So what we could do is add an analogous "cacheJndiObject" flag to = JndiObjectFactoryBean, with the option to turn it off for refetching on = every access - while clients still receive a single reference that does = not break. In the latter case, we'd have to expose a proxy that = implements the same interfaces as the JNDI object, delegating all calls = to the current backend object. This could be useful for SFSB homes and = JMS Destinations, particularly during development. >> >>Of course, the choice between looking up once and refetching on every = access is a bit simplistic. If we could determine that a reference to a = JNDI object or RMI proxy is broken, we could apply a more sophisticated = strategy, just refetching if actually necessary. Unfortunately, I don't = see a reliable way to achieve this for generic JNDI objects. Is there = maybe a specific way for EJB homes, JMS Destinations, RMI proxies, = respectively? >> >> >> =20 >> >I agree that this is the ideal. When you are working with stateless >objects, the best scenario is one where you only do the lookups again >when absolutely necessary, i.e. the object is broken. But 'broken' = means >different things for the different kinds of objects. It may even be >application-specific. > > =20 > >>BTW, hot refetching of JNDI objects also makes sense for local SLSBs, = as requested by a user some time ago: Local SLSBs can be hot-redeployed = too, shutting down the current EJB class loader and starting up a fresh = one. So the "cacheHome" flag on our SLSB accessors makes sense for local = SLSBs too, particularly during development. Likewise, a = "cacheJndiObject" flag on JndiObjectFactoryBean might make sense for a = local object too, if the server supports hot-redeploying the respective = target object. >> >>Juergen >> =20 >> ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
