Hi all. I am experienced in Java, specifically with JSPs and servlets. However, I am relatively new to EJBs. I am working on a app that uses EJBs in a relatively simple way. Basically, either an "Action" class or a Servlet invokes a stateless session bean (no entity beans involved) to remotely either retrieve or update a database value.
My question relates to the servlet implementation. I have seen various examples from online tutorials and books that use this approach:
1. Declare the remote interface as a member object; e.g.:
2. In the servlet's init() method, instantiate that remote interface instance, like:
3. In subsequent doPost(), doGet(), or service() method calls, use that remote interface instance to do stuff.
My question is this: is it a good idea, in a production app with potentially busy traffic, to use a single session bean like that? The servlet could field many requests near-simultaneously, but each request would need to use the same session bean. My gut tells me that this approach is wrong, that the session bean should not be essentially a singleton member variable; rather, a new instance should be called within each doGet()/doPost()/service() method call. That seems to be the whole point of EJBs; the container would manage how to reuse beans, when to create new ones, etc. But I thought I would check, since I have seen different tutorials use the approach illustrated above.
Do any experts have any advice or insight? Thanks in advance! [ September 02, 2004: Message edited by: dave taubler ]
Dave Taubler<br />Specializing in <a href="http://taubler.com/articles/" target="_blank" rel="nofollow">Java and Web Development</a>
I know that for a stateful bean, what you have would be wrong. But I think for a stateless bean it is okay.
The main point to remember is that a stateless session bean is not backed by a single session bean object. It is backed by a pool of objects. Each time you call a business method, a bean is pulled from the pool, the business method is executed, and the bean is put back into the pool to wait for the next request (unless something bad happens). So multiple calls on a remote interface will not turn into multiple calls to the same instance of the bean.
Joined: May 15, 2001
Thanks, you make a good point. My mistake was assuming that a stateless session bean instance was backed by a single object. It makes sense now.