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ürgen höller [werk3AT] wrote:
>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
>
>
|
