Enhancement to Local/SimpleRemoteStatelessSessionProxyFactoryBean [SPR-129]

[spring-projects-issues]

Mike Youngstrom opened SPR-129 and commented

When an ejb is being accessed by a deployment that isn't in the same .ear there is a situation on some servers where an object obtained by a StatelessSessionProxyFactoryBean becomes invalid when the ejb this object references is redeployed or in the case of a Remote EJB if the remote server is shutdown or restarted (probably a bigger issue).

There are a couple of different solutions I'll sugjest, however, I'm no ejb expert so there may be other better solutions.

1. Retry approach. It may be possible to listen for a certain exception when executing. When recieved the Stateless Proxy could attemt to botain a new Object and try again before passing the error on to the client. One possible problem with this approach is perhaps not all containers will throw the same exception for such an error. I believe JBoss throws a NullPointerException.

2. Flag approach. This could be used in combination with Spring core JMS pom.xml #1. Simply add a flag to the Bean that tells it if it should cache ejb objects or not. Since I personally run into this issue a lot when developing it is probably less of an issue in production. Though still a problem the flag could help development and if the performance concerns are warented the user could turn off this flag in production use.

3. Handle approach. Though this may not help performance any perhaps a SimpleRemote bean could work off of a Remote EJBHandle. I believe a Handle should properly reconnect in any case.

Mike

---

Affects: 1.0.1

[spring-projects-issues]

Juergen Hoeller commented

I've just added option 2: a "cacheHome" flag in AbstractSlsbInvokerInterceptor. If turned off, the home object will be refetched on each method invocation. This is clearly intended for development environments.

Colin, do you have any idea regarding option 1 or 3?

Juergen

[spring-projects-issues]

Colin Sampaleanu commented

I am not sure that it is possible for Spring to ever offer a solution which solves this problem in as performant a fashion as user code. In real life code without Spring, the user's code is effectively a short-term cache of the Home and the stub, that they then clean up themselves, so they have ultimate control.

What would probably work for option # 1 is to allow the user to plug in an exception handler for exceptions occuring while using the home. So there would be one for JBoss, one for WebLogic, etc. Most users would never bother since they are probably going to deploy an ear containing both the client and the ejb code, so they will not have this issue, but for those that need it, they could actually go to the extra effort and configure the adapter to retry.

As for option 3, Handles are supposed to allow reconnecting without any issues. However they are not supposed to be very performant. They essentially encapsulare a whole new lookup. I have in the past used a somewhat related approach, where in an HTTP session kept both a stub (to a stateful bean in that case), and a handle. When the cluster would failover to a session on another machine, the transient non-serializable stub would not be there, so the handle would be used instead to get a new stub. So potentially, we could obtain both a home stub and a handle, and then on subsequent usage of the stub, if there is an exception, use the handle. It is probably worth looking at the performance implications of this, although I guess it wouldn't really be that bad, since the handle would only be obtained once, and would only be used in the case of an exception...

[spring-projects-issues]

Juergen Hoeller commented

Option 2 will be part of release 1.0.2; further work might occur for 1.0.3

[spring-projects-issues]

Juergen Hoeller commented

SimpleRemoteStatelessSessionProxyFactoryBean has 3 options now: "lookupHomeOnStartup", "cacheHome", "refreshHomeOnConnectFailure". The latter automatically refreshes the home in case of a java.rmi.ConnectionException, retrying the call afterwards.

Juergen