Understanding SimpleRemoteStatelessSessionProxyFactoryBean

[dcorbin]

We are in the process of migrating to Spring from EJBs. Our first step is to be able to use Spring to get access to our existing EJBs. It looks to me like SimpleRemoteStatelessSessionProxyFactoryBean is the only option directly provided by Spring, and I have a few concerns about using it at this point in our conversion. We really want to take this slowly, and not make "whole hog" changes that require a lot more regression testing.

1) Looking through the code and documentation, it appears that the proxy it returns is effectively a singlton, and there is no way to change it. I believe that the FactoryBean *has* to be a proxy, since it holds the proxy object, all client objects will share this object. Now, presumably, under the covers, there is an EJB proxy that is provided by my specific EJB provider client library. Won't this be a problem if this is *not* re-entrant? Is it part of the EJB spec that it be re-entrant?

2) Spring offers a great benefit, encapsulating the RemoteException nightmare that Sun foisted on us. However, we're reluctant to change the behavior expected by our current client code all at once. Is there some way to regulate this feature?

[Rod Johnson]

1. The client side proxy is a singleton, but it will call the EJB exactly as your own code would have done. So it should not change the semantics of the EJB calling.

2. If you are calling against the remote interface, all methods have throws RemoteException on their signature. In this case, the Spring-generated proxy will recognize this and won't wrap RemoteException in a Spring RemoteAccessException.

[dcorbin]

1. So, looking even closer, with each call to an EJB method an new EJB proxy that is provided by my specific EJB provider client library is created. Is that correct? How much overhead is there (generally) in creating a new EJB proxy - does it involve a trip to the server at all?

2. Thanks. Great news.

[dcorbin]

1. So, looking even closer, with each call to an EJB method an new EJB proxy that is provided by my specific EJB provider client library is created. Is that correct? How much overhead is there (generally) in creating a new EJB proxy - does it involve a trip to the server at all?

I'd still like to understand if an additional trip over the network is required when an EJB proxy is created.

David

[dejanp]

Afaik, you need to go and fetch the EjbHome from the server. Once you have the EjbHome it's cached. How will EjbHome create the Ejb proxy instance is implementation dependant. I can imagine many different brain-damaged implementations that make a network trip on create, but I don't think any major implemenation will actually do it. You could use a tcp/ip monitor to test this. And let us know if you find anything out of the ordinary.