Menu
▾
▴
RE: [Springframework-developer] JNDI object caching and AbstractJndiLocator
|
From: <jue...@we...> - 2004-08-25 12:33:59
|
An EJB stub is different from an RMI stub or proxy for HTTP-based = remoting then: The latter can all be shared without issues, being able = to handle multiple calls from different threads in parallel. So we indeed have to call create for each method invocation in = SimpleRemoteSlsbInvokerInterceptor, at least for WebLogic. Any = experiences on whether this is necessary on other EJB servers? I imagine = that some EJB stubs might nicely handle multiple threads, allowing to = cache the stubs... This is probably not worth thinking about for local SLSB invocations. I = just wonder whether there are more efficient strategies that we can = offer for remote SLSB invocations, as alternative to = SimpleRemoteSlsbInvokerInterceptor. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Colin Sampaleanu Sent: Wednesday, August 25, 2004 2:14 PM To: spr...@li... Subject: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator You can keep around an SLSB stub and use it for multiple calls, but you=20 have to be very careful that all requests do not go through this one=20 stub, as it will potentially become a point of serialization. So this is = really viable only if you also do pooling to handle simultaneous = requests. About 4 years ago, I once had to try to help optimize a WebLogic based=20 app that somebody did, where they decided to be smart, and cached just=20 one SLSB stub in the ServletContext. This stub was used for servicing=20 _all_ requests. Basically WebLogic serialized all requests through the=20 stub. The app could handle less than 5 requests a second. After I=20 suggested going away from the shared stub, along with some small db=20 optimizations, the app was able to handle 75 requests a second... Colin j=FCrgen h=F6ller [werk3AT] wrote: >I've actually changed AbstractJndiLocator's internal workings: = Subclasses are supposed to explicitly call a "lookup()" method now, = receiving the freshly located object, rather than getting a = "located(Object)" callback on startup. This is necessary to implement = true hot fetching of the JNDI object (just in time for calling a method = on it, and throwing it away again right afterwards), without temporarily = storing it in an instance variable. >=20 >In terms of backwards compatibility, it's probably better to keep the = AbstractJndiLocator as-is (deprecating it though) and put the new code = into a JndiObjectLocator base class. Our remoting proxies can then = derive from that new base class, with explicit lookup calls whenever = they need them. >=20 >There's actually four strategies that we could support out-of-the-box: >1. look up the JNDI object on bean initialization, storing it for later = usage >2. look up the JNDI object on bean initialization (to determine = interfaces or for validation), refetching it for every operation >3. look up the JNDI object on first need (first call to = JndiObjectLocator.lookup), storing it for later usage >4. look up the JNDI object for every operation (every call to = JndiObjectLocator.lookup) >=20 >Number 1 is current standard behavior. Number 3 requires synchronized = access to the stored JNDI object, but seems to be the appropriate = behavior for EJB lookups (avoiding lazy-init on the bean and all objects = that depend on it). Number 4 allows hot-redeploy of EJBs, mainly during = development; number 2 does the same, but performs early validation, = assuming that the lookup already works on startup. >=20 >Regarding usage of remote EJB homes: What alternative strategies are = there for our SimpleRemoteSlsbInvokerInterceptor, i.e. what could you do = more efficiently if you accept some assumptions about your server? I = could imagine that on some servers, creating the SLSB instance once and = keeping it for the lifetime of the client application would work: Often, = the SLSB instance is just a proxy that creates new calls to the servers = every time, not allocating any resources on the server... >=20 >Juergen >=20 > >________________________________ > >Von: spr...@li... im Auftrag = von Colin Sampaleanu >Gesendet: Di 24.08.2004 21:01 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator > > > >I don't think it's a big deal if AbstractJndiLocator doesn't do an >immediate lookup on initialization. I actually complained about the = fact >that it did this a while ago, and this is why most people are >recommended to make their EJB proxies lazy, since a lot of the time the >JNDI tree is not ready at the time the JNDI lookup is done, if the = proxy >is not set as ready, depending on the EJB environment. I would be >surprised if too many people are using this class, as opposed to >JndiObjectFactoryBean... Is this the only thing you want to change in >AbstractJndiLocator? > >As for the question about remote communication on the usage of the = home, >I don't think there's any guarantees here. A clustering EJB >implementation could very well do some remote communication on create >calls, if that makes the job of the cluster management code easier. It >is typically the bean stub itself that handles cluster failover, so I >dont think the home object actually has any real need to do remote >communications, but I don't remember there being any contract = forbidding >it. I'm working from memory, but I do seem to remember that EJB 2.0 = does >recommend that you now stay in your own VM, when creating a new stub, >for efficiency reasons. I.e. load balancing is no longer supposed to be >handled by automatically (by default) handing off to EJBs on different >cluster members, with that being recommended only for failover. > >Colin > >j=FCrgen h=F6ller [werk3AT] wrote: > > =20 > >>I've just checked remote proxy caching throughout our remoting = strategies: RmiClientInterceptor has a "cacheRmiProxy" flag now, = allowing to perform a fresh lookup if turned off. Analogously, = JndiRmiClientInterceptor should be able to refetch its JNDI object now = if the flag is turned off. >> >>Our EJB accessors have a similar "cacheHome" flag, which was = implemented a bit crudely: If turned off, it simply overwrote the = instance variable for the home object on every invocation - in a = non-thread-safe manner. Preferably, it should simply fetch a new = temporary proxy on each invocation in that case, just like = RmiClientInterceptor does. >> >>Unfortunately, this means that our AbstractJndiLocator base class = should change: It should not perform a lookup on initialization in any = case and call located, but rather allow subclasses to explicitly call = lookup when needed (i.e. either on initialization or on each invocation, = depending on the respective flag). >> >>I've already adapted everything accordingly: All our remote accessors = (which are based on proxies that need lookup, i.e. not the HTTP-based = ones) have consistent support for configurable caching of proxies now. >> >>The question is: Can we live with the incompatible change in = AbstractJndiLocator class (which is somewhat internal anyway)? Else, I = could introduce a different base class for the above use case. However, = that one would be very similar to the old AbstractJndiLocator, and we = don't really have a need for the old locator class anymore... >> >>----- >> >>On a related note: Does a create call on a remote SLSB home usually = involve actual remote communication, or is it rather implemented as = local operation that returns a proxy for an actual SLSB instance? I was = wondering whether our SimpleSlsbInvokerInterceptor actually causes = communication overhead through its create call for each method = invocation... >> >>Juergen >> =20 >> ------------------------------------------------------- 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 |
