[Springframework-developer] JNDI object caching and AbstractJndiLocator

[<jue...@we...>]

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