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

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

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).
=20
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.
=20
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.
=20
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.
=20
Juergen
=20

________________________________

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?
>=20
>
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