Are References to Sessionbeans threadsafe?

[micho]

I have a servlet talking to a Sessionbean.

Is it allowed -regarding threadsafeness - to obtain the manager in the servlets init() method and store it in an instance-membervariable of the class.

public class LzServlet extends HttpServlet {

 MandantenManager mm =null;

 public void init(ServletConfig config)
 {
 try
 { InitialContext ctx = new InitialContext();
 mm = (MandantenManager) ctx.lookup("BBCS/MandantenManagerBean/remote");
 }
 catch (Exception e)
 {
 e.printStackTrace();
 System.exit(-1);
 }
 }

Is getting the initialcontext and the lookup an "expensive" operation?

[alrubinger]

So the question is: Are RMI Stubs in JNDI Thread-safe; may they be accessed concurrently?

The EJB Spec, 4.7.11, has this to say about Non-reentrant Instances in Session Beans:

The container must ensure that only one thread can be executing an instance at any time. If a client
request arrives for an instance while the instance is executing another request, the container may throw
the javax.ejb.ConcurrentAccessException to the second client[24]. If the EJB 2.1 client
view is used, the container may throw the java.rmi.RemoteException to the second request if
the client is a remote client, or the javax.ejb.EJBException if the client is a local client.[25]

...which is in relation to the "instance", the implementation residing on the server, not the stub you're storing as an instance variable in your servlet.

So, if your Session bean below is Stateful, this ensures that every call from that stub will be invoked on the same instance. Meaning that every request passing through that servlet will execute in the same session (which you probably don't want anyway), and that if two users access it concurrently, an exception will be thrown.

Couldn't find a clear answer regarding the thread safety of stateless session stubs. If the container does the job of invoking each call on a unique instance without allowing 2 threads in the same instance at the same time, I can see why this would be a valid design choice.

Anyone know? Cool to cache the local stubs of a SLSB in a multithreaded environment?

As an aside...if an exception is encountered, System.exit()? Bring down your whole server if one request encounters an error?

S,
ALR