Menu
▾
▴
Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator
|
From: <jue...@we...> - 2004-09-01 08:17:15
|
The only runtime disadvantage of "lookupHomeOnStartup"=3Dfalse and = "refreshHomeOnConnectFailure"=3Dtrue is that it requires synchronized = access to the home object. However, that's just very minor overhead. =20 Additionally, "lookupHomeOnStartup"=3Dfalse does not eagerly validate, = so misconfiguration will just show on first access rather than on = startup. As you say, the home is simply not available on web container = startup with many EJB containers, so it's probably better to accept late = validation as tradeoff. =20 I guess it makes sense to use the same defaults for the RMI accessors. = After all, an RMI server might start later than the web server, or = restart while the web server stays up. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Mi 01.09.2004 05:43 An: spr...@li... Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator I agree that the renaming makes sense. I would go for sure with "lookupHomeOnStartup"=3Dfalse as a default. As for "refreshHomeOnConnectFailure"=3Dtrue, I can't really think of any negative consequences. Code all looks ok to me, I'll give it a runthrough tomorrow. j=FCrgen h=F6ller [werk3AT] wrote: >How do we proceed with the defaults? Should we make = "lookupHomeOnStartup"=3Dfalse and "refreshHomeOnConnectFailure"=3Dtrue = the default? > >FYI, I've renamed RmiClientInterceptor's "lookupRmiProxyOnStartup", = "cacheRmiProxy" and "refreshRmiProxyOnConnectFailure" to = "lookupStubOnStartup", "cacheStub" and "refreshStubOnConnectFailure", = respectively. The RMI docs consistently call that thing "stub", so I = thought we should too, as it also avoids confustion with an AOP proxy as = provided by RmiProxyFactoryBean. > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] >Gesendet: Mo 30.08.2004 15:56 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator > > > >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 >mail below (haven't looked at the code yet), it sounds like the >lookupHomeOnStartup option is on by default. I know that this makes the >code completely backwards compatible, but IMHO it probably makes more >sense to have it default to off. In a lot fo containers you had to use >the lazy-init=3Dtrue setting on the bean previously so you wouldn't = access >the ejbs before they were actually loaded, so I think most users will >want this on by default. Of course, there are some people who will get >an error message (on bad setup) later rather than sooner with this >setup, but I think it's going to be less people than get burned by the >fact their EJBs are not loaded yet. > >I'll update the ejbtest integration test/sample at a minimum to test >some of the new options. I should be able to update the ejb docs to >mention the new options. > > >j=FCrgen h=F6ller [werk3AT] wrote: > >=20 > >>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. >> >>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"). >> >>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. >> >>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? >> >>Juergen >> >> >>________________________________ >> >>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 >>> >>> =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 |
