Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator

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

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:

>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