Menu
▾
▴
Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator
|
From: <jue...@we...> - 2004-08-29 14:23:50
|
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. =20 * 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". =20 * 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. =20 * 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. =20 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. =20 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. =20 Juergen =20 ________________________________ 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: >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? > > 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. > >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 > > ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
