[Springframework-developer] Caching and SimpleRemoteStatelessSessionProxyFactoryBean

[Kristoffer M. <kri...@gm...>]

Hi, guys.

I am posting as I have a challenge these days regarding remoting based on
the SimpleRemoteStatelessSessionPro xyFactoryBean. I have a client
application proxying through this class to remote jvms exposing SLSBs. The
problem relates to the application servers hosting the EJBs and their
availability - sometimes the remote VMs are restarted. This is not a proble=
m
for any of the Weblogic-based VMs but one instance is running on an old
JBoss instance (3.0.4 running jdk1.4.1_01) - which is troublesome.

If the remote JBoss VM is restarted at some point, the JBoss instance will
propagate java.rmi.NoSuchObjectExceptions to the client until both the
server and client VMs are restarted. Allegedly, this happens because when
the JBoss InitialContext implementation holds hard references to the server
class and these references can be invalidated i.e. by restarts (hence the
NoSuchObjectExceptions).

My Spring-managed bean is defined as follows (some property-file refs were
hardcoded and class-names were obfuscated in the snippet):

    <bean id=3D"theRemoteEjb" class=3D"
org.springframework.ejb.access.SimpleRemoteStatelessSessionProxyFactoryBean=
"
lazy-init=3D"true">
        <property name=3D"jndiName" value=3D"jndi/remoteserver/TheEJB"/>
        <property name=3D"jndiTemplate">
            <bean class=3D"org.springframework.jndi.JndiTemplate">
                <property name=3D"environment">
                    <props>
                        <prop key=3D"java.naming.factory.initial">
theserver.thecompany.no:1234</prop>
                        <prop key=3D"java.naming.provider.url">
org.jnp.interfaces.NamingContextFactory</prop>
                    </props>
                </property>
            </bean>
        </property>
        <property name=3D"lookupHomeOnStartup" value=3D"false"/>
        <property name=3D"businessInterface" value=3D"
no.theserver.thecompany.TheInterface"/>
    </bean>

If I'm not completely mistaken, a workaround of the problem at hand would b=
e
to define the bean as a prototype/non-singleton, i.e. singleton=3D"false".
While this would not be optimal with regards to performance in remote
invocations for that specific EJB, this  approach should definetely solve
the actual problem.

Am I correct in my assumptions that this would cause new lookups for all
remote invocations thus resolving the problem?

Regards,
Kristoffer Moum
Objectware